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PREFACE 


The third annual Technology Conference, sponsored by the NASA 
Headquarters ADP/Office Automation Management Branch, was held 
June 6 and 7, 1984 at Langley Research Center (LaRC). James D. 
Radosevich of the ADP/Office Automation Management Branch was 
conference chairman, Andrew Swanson was conference host, and 
Edna Davidson of BDSD was the conference coordinator at LaRC. 

The purpose of these conferences is to provide an open forum for 
constructive information exchange among NASA technical Automatic 
Data Processing (ADP) personnel. The theme for each conference 
is selected by conducting a survey of NASA ADP personnel through 
the NASA Inter-Center Committee on ADP. Thus far all three con- 
ferences have had the same theme - NASA Administrative Data Base 
Management Systems. 

The 71 conference attendees heard 17 presentations and partici- 
pated in two roundtable discussions. Tours of some LaRC data 
processing and research facilities were conducted as part of the 
conference . 
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STRATEGIES FOR CONVERTING TO A 
DBMS ENVIRONMENT 

Dave M. Durbin 
Data Base Administrator 
Ames Research Center 


Ames Research Center (ARC) installed ADABAS on the administrative computer, 
an IBM4341 running VM/CMS. Prior to the installation of ADABAS, the only 
data base-like system used at Ames was a product called QBE (Query-by- 
Example) . This product was installed and an extract of the payroll and 
personnel file was loaded as a table under QBE for use by the Personnel 
Office and Resources Management Office for ad hoc queries. 

The strategy of converting to Data Base Management Systems processing tech 
niques consists of three different strategies - one for each of the major 
stages in the development process. Each strategy was chosen for its ap- 
proach in bringing about a smooth evolutionary type transition from one 
mode of operation to the next. 

The initial Strategy of what we call the "indoctrination stage" consisted 
of the following elements: 

* Provide maximum access to current administrative data as soon as 
possible. 

* Select and develop small prototype systems. 

* Establish a user information center as a central focal point for user 
training and assistance. 

* Develop a training program for programmers, management and ad hoc 
users in DBMS application and utilization. 

Each of these strategies has one or more "sub-strategies" if you will. 

Each of tnese serves to highlight the purpose and intent of the main strat 
egy. 
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By providing maximum access to current administrative data as quickly as 
possible, we hoped to achieve the following advantages: 

1. Casually introduce on-line computing to the non-ADP professional 
with little impact on the current systems. 

2. Provide training to the user community using the data they are 
familiar with and, thus, flattening the learning curve. 

3. Decrease requests for AD HOC reports from the user as they gained 
proficiency in performing their own requests - resulting in more 
time available to the DP staff in developing ADABAS systems. 

4. Providing a basis for determining efficiencies in file design 
based upon what type of queries the users performed. 

5. Satisfy the users desire to have more access to their data. 

The trade-offs were: 

1. Possible system degradation due to less efficient file design, 
users performing inefficient queries, etc.. 

2. Tod much freedom given to the users which may have to be taken 
away later. 

3. Worst possible case - the user would be turned off immediately 
and develop a negative attitude toward on-line processing. 

4. Enlarge the task of cleanup - to make data definitions conform 
to standards, etc.. 

To complement this approach, we developed a plan for establishing a user 
information center to serve as the central focal point for handling user 
training and assistance. The plan also called for developing training pro- 
grams for DP personnel, management and ad hoc users. 

Another part of the plan called for selecting and developing small "stand- 
alone" systems to provide needed computing capabilities where none existed. 
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Expected benefits of this particular strategy were: 

1. Reduce the impact of non-experience by using less complicated 
systems. 

2. Lessen the impact of system complexity in overcoming the learn- 
ing curve. 

3. Gain experience in developing on-line systems in DBMS environ- 
ment. 

4. Provide new service to user community and demonstrate the capa- 
bilities of the DBMS. 

5. Development process could be used as initial guide to on-line 
systems development. 

The last piece of the "indoctrination" strategy was to develop an effective 
training program for each of three groups of people. 

1. The DP professional training consisted of specific training 
in the internals of the data base management system, courses 

in. the procedural language and a seminar in applications develop- 
ment methodology. 

2. The top and middle management training consisted mainly of a 
series of briefings and demonstrations. 

3. The training for the Center ad hoc users was primarily an over- 
view of the DBMS and specific instruction in the procedural 
language with emphasis on query. This training is provided 

on several levels from beginner through advanced. In addition, 
a selected group of users attended the seminar on PDM 80. 
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This strategy was rather straight forward and simple. There was little 
concern for efficient design, file layouts, normalization of entity 
classes, or any such buzzwords that you hear about today in the data base 
world. The emphasis was on experience and experimentation, learning what 
could be done with the data base and alternative ways of doing it. Without 
experience with a data base management system - and Ames had little of that 
- these "modern" concepts had little meaning and were difficult to relate 
to. These new ideas and concepts would become more important in the next 
stage of the development process, but the indoctrination stage was just 
that - indoctrinate the community to the new tool - the Data Base 
Management System. The fastest way to do that was to keep things simple. 
Before I go on to explain the components of the next stage of the develop- 
ment process, let me elaborate a little on the results of the initial 
stage. 

The first step was to load the most used files from the current batch sys- 
tems into the data base for access by the owners of the data for ad hoc re- 
porting. The first files loaded were the personnel and payroll system 

The files were defined with little concern for standard data names 
and proper data base file design. The arrangement of the fields was based 
on a combination of the current record layout and a limited knowledge of 
what fields were most frequently accessed. The objective was to get the 
data into the data base. Some of the data was loaded and a few programs 
written to assist the personnel department in accessing the data. One such 
program was the individual employee record which basically displayed an 
individual employee's personnel status and action history on the screen. 

The other programs were a series of menu-driven which assisted the user in 
operating the system and developing queries without having to learn all the 
commands or syntax. The initial reaction was one of caution. The user was 
unsure of his capabilities to learn and effectively program queries with 
the new language NATURAL, which is considerably more complex than QBE which 
they had been using. However, it was only a matter of a month or two 
before they were using NATURAL exclusviely. This was due to several 
reasons: Primarily because the file loaded into ADABAS was more complete 

than the one in QBE and the ADABAS file was reloaded every day that an 
update had taken place, whereas the QBE file was loaded only at the end of 
each, pay period. Other factors were the quicker response in ADABAS and the 
personnel department had hired a summer student who was eager ta learn 
NATURAL and had developed some rather useful reports using NATURAL which 
greatly assisted the organization. Therefore, after a few short months, 

QBE was quietly phased out and the lease agreement terminated. ADABAS and 
NATURAL were accepted by the users. In fact, the user community was 
becoming excited over this new source of information and wanted more - not 
only from the data processing department - but they wanted more knowledge 
about the data base and NATURAL. They wanted to do more for themselves. 

The logical place for the users to go was to the user information center 
that was established when QBE was installed, but had seen little activity. 
The users came here for answers. No formal training was provided yet for 
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the users. The training was concentrated on the DP personnel. Until that 
training was completed, training of the users could not commence. 

With the help of Langley Research Center, we loaded files from other sys- 
tems with the Data Base and we obtained "on loan", a highly qualified in- 
structor to provide advanced NATURAL training to our DP staff and to assist 
in developing a formal training program for the user community. Meanwhile, 
development of three small systems in ADABAS and programmed primarily in 
NATURAL was under way. The three projects were: 


1. LIRS II - a legal information retrieval system for maintaining 
an inventory of legal documents relating to the 80x120 Foot Wind 
Tunnel litigation. 

2. TPS - Treasury Payments System for processing of miscellaneous 
payments . 

3. System Documentation Library for maintaining inventory and con- 
trol of systems documentation. 


The LIRS II System was developed in four weeks with an additional two weeks 
spent in enhancing the query portion of the system. 


The Treasury Payments System was developed in eight weeks. 


The System Documentation Library was developed over a longer period of 
time, approximately ten weeks, by a programmer who had little experience in 
NATURAL programming. This system was later scrapped and redone within a 
two week period as a class project in advanced NATURAL techniques. 


These three systems were selected for development based on three factors: 

1. There was an immediate need for the data processing application 
and the system did not exist before. 

2. Expected development cycle was short and if the system had to be 
redone, it could easily be accomplished. 

3. The systems were not complex. 

These three systems are still in operation today and require minimal main- 
tenance - in fact - a routine maintenance schedule has not yet been estab- 
lished. 


These three projects led to the development of NATURAL programming stan- 
dards and system design standards, but most of all, they served to show the 
capabilities of ADABAS and the productivity of the NATURAL programming lan- 
guage to the .DP department and to the Center. 
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By the end of the first phase of development (and there is no definite 
cutoff point between the first and second phase) , it was evident that the 
DBMS dramatically and permanently changed the concepts and attitudes toward 
computing at Ames. 

The user information center conducts regular, formal training classes for 
the user community. The users are finding that they can meet some of their 
information needs without the assistance of the DP department. Communica- 
tions between the DP department and the users is at an all-time high. The 
user has learned the importance of their involvement in system design and 
development . 

There are some negative aspects to this strategy which I will list below; 
however, these shortcomings were recognized at the inception. Dealing with 
these issues would be a major part of the second phase in the evolutionary 
process. 

1. Security issues. Security of the data against unauthorized 
access or destruction was dealt with on a very low key basis. 
Minimal security precautions were established primarily to pro- 
tect privacy data against unauthorized access and to insure 
integrity of on-line systems which did not have a backup batch 
system. While these security procedures are not foolproof, 
reports of the data base activity have shown no violations and 
there have been no problems detected. 

2. Data dictionary role in the DBMS. Very little attention was 
paid to the data dictionary and its role in managing the data 
base environment. Consequently, the first phase saw no stan- 
dardization of data names and data definitions, data redun- 
dancy and data relationships were not defined. 

3. Data base tuning and capacity planning. Obviously this was 
nearly impossible in the first phase of our strategy primarily 
due to lack of any knowledge in this area. 

This issue became important sooner than anticipated. With the installation 
of the NEMS System, the data base performance ground to a snail '.s pace. 
Within a couple of weeks, however, through adjusting of buffer areas and 
some blocking factors of data base data sets, the performance was brought 
back to a tolerable level. Still, I was not satisfied and could foresee 
difficulties in the near future if performance could not be improved. The 
performance did not appear to be as efficient as some COMPLETE users were 
experiencing. To make a long story short, we finally came across the fact 
that CMS was single threading all of its I/O, and that Cornell University 
had developed BDAM emulation software which allowed overlapping of I/O. 
Within another couple of weeks, we had installed the software on the data 
base machine and were experiencing a ten-fold improvement in response 
times. 
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Overall, the objectives of the first phase of the strategy were well 
achieved. The users could now have access to their data in a realtime 
sense. They were well on their way to being able to ask the right ques- 
tions and getting the right answers to those questions without waiting in 
line at the data processing department door. 

The second phase is well under way. The main objective of the second phase 
is to develop an effective, efficient and viable methodology for develop- 
ing, maintaining and utilizing the Center's information resources. 

In this phase, the issues of security, data structures, file structures, 
and proper data defintions become important. To assist us and to get ex- 
posure to the latest methodologies in data base development, we hired UCLA 
professor. Dr. Alphonso Cardenas, to provide a seminar on his methodology 
"PDM 80" and to provide consulting services during the first development 
project using his methodology. That project started in January of this 
year and is scheduled for completion in August. It is planned that the 
results will be a system with a well documented, developmental methodology 
that will serve as a model or prototype for all future development efforts. 
The project encompasses the R&PM functions of the Resources Management 
Office. 

Also scheduled in this phase, is the installation of NATURAL security and 
the development of required procedures to assure data integrity, protec- 
tion of sensitive data from unauthorized disclosure, and protect the entire 
data resource from destruction. 

Another important issue in the second phase is the development of a truly 
integrated data dictionary system. The objectives of the data dictionary 
are: 

1. Document and define all the entities, attributes, classes and 
relationships that comprise the Center's information resource. 

2. Standardize data names by establishing naming conventions. 

3. Define systems, programs, files and data elements used in them. 

4. Define the owners of the data. 

5. Provide the capability for determining and subsequently managing 
data and system changes. 

I might add that included in this data dictionary is all data considered to 
be part of the Center's information resource regardless of where it re- 
sides. 

Finally when this is all accomplished, we are ready for the final phase in 
evolving toward DBMS technology and that is the incorporation of the data 
bases into a complete automated office management system. "Office automa- 
tion" to use the buzz word of today. 
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Even today with the increasing use of the micro-computers as work stations 
with their own data base systems, word processors, and communications with 
he main-frame, office automation is a fact of life at Ames and is rapidly 
increasing. 

Many of the organizations at Ames, especially in the administrative areas, 
have in one short year gone from computer-phobia to computer-literacy. The 
data processing department is evolving from that of the doer to the role of 
the consultant. 

What’s ahead for Ames? In the short term, SOFTWARE AG has offered to allow 
Ames to test their new AD ABAS /VMS product for the VAX. Currently, Ames is 
loading financial data from the IBM Financial System onto one of the VAX 
machines and using INGRES to query the data. 

The test period will be used to compare the two DBMS'. If ADABAS performs 
as well as INGRES, we would then purchase ADABAS/VMS which will allow us to 
transport the NATURAL programs from the IBM to the VAX. 

Several menu-driven, ad hoc query facilities have been developed which 
provides the capability for the user to extract data from the data base 
files without seeing or using one word of NATURAL language. One of the 
systems allows the user to export data to his micro-computer for use by a 
micro-based data base system such as Lotus 1-2-3. These systems have been 
a real hit with the users and more of these are in the planning stage. 

Conclusions: 


Starting small is important. 

Several small systems developed implemented will achieve immediate recogni- 
tion and subsequently, strong support for the capabilities of the system 
and the DP department. Starting small will allow your DP professionals to 
gain experience, and at the same time, achieve some demonstrative suc- 
cesses. 

Access is the key to success. 

Provide the user with the access to his data and with a small selection of 
software products or tools for the user to manipulate the data. Use the 
information center to train and assist the users; to answer their ques- 
tions; to develop their skills in writing their own programs. 

User information center is vital to success. 

At first, if the center is nothing more than that of a solution center, 
i.e., providing answers to users questions on how to write a query, it will 
still serve to nurture the non-DP professional in finding his own solu- 
tions. In fact, in some instances, you may even find the information 
center personnel benefiting from the approach of some users. It seems as 
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an exchange center - an exchange of ideas and techniques between the 
administrative professional and the data processing professional. Result: 
a more solid knowledge base for developing applications and an atomosphere 
of cooperation and common interests. It serves to gradually bring about a 
change from the old method of the users tasking the DP department with an 
application or problem, and the DP department providing a solution which 
often the user is not completely satisfied with, to a new attitude. 

1. One of working together to achieve a common purpose. 

2. One in which the user shares in the responsibility and credit 
for the success of a project. 

Nearly all of the modern DBMS development methodologies today, stress the 
importance of a well defined, comprehensive integrated data dictionary. I 
strongly agree with that concept. It should be the map of the data base 
system, but don't waste effort on attempting to standardize data names of 
existing files being loaded into the DBMS. Load the file with the existing 
names, define them as well as reasonably possible, but remember to start - 
the key is access. Often using names that the user is familiar with is the 
best course in getting them through the indoctrination phase - and the ad- 
vanced user is an excellent source for developing names and definitions of 
the data during the later phases of development. 
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EFFECTIVE ORGANIZATIONAL SOLUTIONS FOR IMPLEMENTATION 
OF DBMS SOFTWARE PACKAGES By: Doug Jones 

Introduction/Strategic Plan 


This paper will use the Space Telescope Management Information 
System development effort as a guideline for discussing 
effective organizational solutions used in implementing DBMS 
Software. The paper will not attempt to be all inclusive but 
rather will focus on the importance of strategic planning. 

In addition, methodologies will be examined that offer viable 
alternatives for successfully implementing DBMS software. 

The paradigm for effective implementation of a 
Management Information System (MIS) is a strategic plan. The 
idea of the strategic plan is straightforward in concept: 
where do you want to be and how do you get there. More 
importantly, it is the background against which the necessary 
managerial and technical tradeoffs are made in order to 
successfully implement a Database Management System (DBMS) as 
part of the MIS effort. 

It has been found to be useful by system development 
teams to express this strategic plan visually as an 
Information System Architecture. The general recommendation 
is to a avoid a rigid detailed hardware/software architecture 
which is incapable of responding to evolving managerial 
needs. Instead, the guiding principle is to construct the 
architecture to conform to the organization's management 
structure. This management structure or organizational 
setting includes the consideration as to whether the 
operation is centralized or decentralized, and what is the 
prevalent management philosophy. 

This information system architecture does not have to 
be complex. In fact, simplicity is an asset. A few 
diagrammatic repr esentations can prove to be very effective. 

As decision alternatives are developed, such as shifts in 
requirements, vendor evaluations, or software selection, they 
are all examined with respect to this Information System 
Architecture. It is several of these major decision 
alternatives which will be discussed, and implementation 
alternatives offered. 

In harmony with this strategic plan, there must be a 
senior decision maker, functioning as the architect of the 
Information System Architecture. This authority should be 
one individual, or certainly no more than a few individuals, 
who can accurately determine and enforce organizational 
requirements . 
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For the NASA Space Telescope Program, this Information 
System Architecture includes the general requirement to 
integrate contractor financial data, reported via a diverse 
management tracking structure, with relevant program 
technical feedback. This data must be combined and reported 
in a timely fashion. More specific requirement goals were 
included, outlining the specific types and level of program 
financial data and the specific technical data needed. The 
organizational setting was complicated by the fact that the 
Space Telescope Program is a major NASA program, which at the 
time of the MIS start-up was well underway in terms of time 
and total dollar expenditures. The strategic plan included a 
need for offering a benefit to the on-going program in the 
near term, and the development of a system to meet future 
NASA program requirements. For the NASA Space Telescope 
Program Management Information System, the crucial chief 
architect role belongs to Mr. James Welch, NASA Space 
Telescope Program Manager. 
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Shifting User Requirement? 


The most immediate difficulty for implementation of a 
DBMS package, or any software system, is dealing effectively 
with shifting user requirements. All projects, whether they 
are software or engineering, involve a series of calculated 
trade-offs made during the difficult course to completion. 
Taken in this context, the problem of shifting requirements 
should not be surprising, nor unexpected. 

Even more important than this realization, is the 
crucial combination of establishing a baseline requirement 
and top management commitment. It is this combination that 
permits effective solutions for handling shifting 
requirements. The importance of a strategic plan expressed 
as an Information System Architecture for establishing top 
management commitment has been discussed. One effective tool 
for establishing the baseline requirement is prototyping. 
Prototyping is the process whereby an initial working 
software system is constructed for presentation to management 
and the user community. In fact, the presentation process is 
the key. The goal of the presentation is to make the users 
an integral part of the development process. By 
demonstrating an electronic strawman early in the development 
cycle, users are presented with less of an abstraction than a 
simple verbal or written explanation would lend. This 
electronic strawman allows the system developers to elicit 
meaningful responses from selected users early on in the 
course of system development. This electronic strawman can 
be as simple as a series of example screen formats that may 
be paged through in the manner that the proposed system will 
function. 

As development continues, the prototype continues as 
the vehicle for acceptance of changing requirements. It is 
important to note that this prototyping approach accurately 
reflects the iterative nature of software development. 

Changes will continue to be received and accepted as they 
are approved. Management's expectations should not reflect 
a static system, but rather should be for a controlled audit 
trail of changes, all of which relate back to the strategic 
plan as expressed in the Information System Architecture. 

For the Space Telescope Program the prototype Program 
Management Information System (PMIS) has been completed. 

This PMIS 1.0, representing the baseline requirements, was 
accomplished using the Digital Equipment Corporation (DEC) 

VAX 11/780 executing the INFO Database Management System. In 
addition to continued user training, production control 
procedures are being established to identify, implement, and 
monitor requested changes to the PMIS 1.0 System. As data 
loading continues, it is expected that further enhancements 
will continue to be made. 
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DBMS Vendor 


After establishment of a strategic plan in the form 
of the Information System Architecture, another early and 
crucial issue in the chronology of MIS development is the 
establishment of a reliable working relationship with the DBMS 
vendor. This is an important step, whether or not the DBMS 
package has already been selected. If the DBMS evaluation is 
being done, vendor support becomes one of the decision 
criteria. If an existing DBMS is already in place and is 
satisfactory, it still benefits the project to review the 
nature and quality of vendor support. Vendor support is 
always important because the vendor can be the major link to 
viable alternatives for use of the software product, both 
during and after the software development effort. 

Foremost in the evaluation of vendor support is their 
perceived ability to meet the organizational goals, as 
outlined in the Information System Architecture. This 
however, is the composite of many indicators. One 
recommended first step is a phone call to other user sites, 
followed by visits and evaluations of these operations. This 
should yield a realistic impression of the sites relative 
success and quality of on-site support. Users who are 
performing a similar operation to the proposed plan are the 
most valuable contacts. As part of this initial evaluation, 
the financial position of the vendor should be examined to 
ensure at least the possibility for a long-term relationship. 

Another valuable indicator for evaluation is vendor 
supplied training, and the existence of a user group. The 
emphasis placed on training is a strong indication of the 
vendors intent to support the user sites for the long-term. 

In particular, multiple class offerings both on and off-site 
with flexible scheduling are all positive signs for vendor 
support. In addition, a strong user group can be a 
considerable asset. The user group can be another source for 
training and creative ideas for use of the DBMS product. No 
one single vendor will put their product to the variety of 
uses that a user community will in just a short period of 
time. During this second phase of evaluation, plans should 
be formulated to ensure staff training and making contacts 
for later direct support. 
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Another consideration is the vendors' philosophy 
towards processing maintenance requests and changes to their 
DBMS product. Maintenance requests should be handled in a 
disciplined fashion. The presence of a strong user group can 
yield additional leverage for insistence that a selected 
change be implemented. Another leverage factor is the size 
of your account and the type of work you are proposing. A 
project for a large organization, that is making full use of 
a vendor's product will command the vendors attention. Such 
a relationship can be advantageous to both sides. The user 
gets prompt attention while the vendor gains potential 
marketing advantage. With more hardware vendors supporting 
DBMS products, a user with large dollar expenditures tied up 
in hardware may consider using the same vendors DBMS 
software. Bargaining leverage is gained and technical risks 
may be minimized because the software was developed for the 
hardware in question. Finally, the contract itself offers 
the possibility for bargaining leverage. A lease agreement 
may make better financial sense and offers greater bargaining 
flexibility than an outright purchase. In particular, the 
prototype process allows real time evaluation before 
commiting to a product. 

Whether the DBMS package has been procured or not, a 
technical evaluation should be made to determine 
compatabi li ty with design requirements. This subject is 
thoroughly discussed in current literature and will not be 
greatly expanded on here. One consideration does .however, 
deserve emphasis. Any DBMS package selected will be lacking 
with respect to some capability or capabilities desired by 
the user community. This is why the types and likely 
strengths of your leverage should be evaluated beforehand. 

The reality of work-arounds will soon become apparent. 
Work-arounds is the concept of seeking alternative software 
solutions for a problem that is unresolvable in the 
short-term. This inevitability should be reflected in the 
evaluation process. A more complex DBMS is more difficult to 
manipulate. Make sure the applicationC s) planned require the 
degree of complexity you are buying. Again, the prototype 
process can be useful in making this final determination of 
DBMS suitabliity. 

For the Space Telescope Management Information System, 
the alliance with the software DBMS vendor was complicated by 
an intermediate agreement with another third-party vendor. 
This lead to some negotiating difficulties when faced with 
technical deficiencies with the DBMS. This situation was 
resolved within the vendor's organization by using the 
leverage NASA had due to the lease agreement, and the implied 
pressure of negative publicity because of the importance of 
the NASA account. 
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Admittedly, it is more difficult to break-out 
intermediate deliverables for tasks such as development of 
the DBMS system calculation logic. For such tasks, the 
recommendation is to break them down to correspond to the 
functional capability of the system. For instance, the 
calculation logic may be broken out into three sections. The 
input of the data to be calculated, performing the 
calculations, and reporting the calculation results. To the 
development staff the process is of course, more complicated. 
But, this approach is more understandable to general 
management. It is the responsibility of the system 
developers to represent the difference in relative difficulty 
by demonstrating time differences in the schedule. For the 
calculation logic example, the necessary design, writing, and 
testing of the calculation logic is more difficult than 
either inputting the data to be calculated , or moving the 
results to be reported. 

For the Space Telescope Management Information System 
this general approach was followed. A time schedule with 
associated deliverables was established and reported to. Of 
the three schedule delays identified, only one was related 
to a software problem with the INFO DBMS. In all cases the 
underlying problem for the delay was worked until a solution 
was reached. 
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Supporting Management 


Effective implementation of a DBMS requires the 
continuing support of management considerations. The 
strategic plan is the starting point for establishing 
management commitment. The prototype is an excellent tool 
for handling shifting requirements. Vendor support is a 
requirement for identifying viable software solutions. 
Everything is set except for the time line of development. 
Continued management support requires an accompanying 
schedule. 

The system development staff should be able to track 
and report to a time line at all times. The idea of a 
strategic plan and corresponding schedule is not a 
revolutionary concept. However, since software projects are 
frequently late, it is equally obvious that merely developing 
a schedule is not adequate. Several suggestions are in 
order . 


The reality of shifting requirements has been 
discussed. Such shifts need to be documented and approved. 
The prototyping approach allows for inclusion of these 
changes, which is important to prevent uninterrupted 
development. In parallel these changes must be noted with 
respect to the changes in schedule. The realities of 
schedule slippages should be discussed immediately and not 
appear as a surprise on the original anticipated project 
complete date. Tracking the inevitable deviations from the 
original plan in concert with the prototype development is an 
on-going process. 

In order to fine-tune this process, system developers 
have found it useful to establish intermediate product 
deliverables throughout the lifecycle development process. 

The purpose of this effort is to prevent serious 
misunderstandings from being identified late in the 
development process. Although the complete DBMS-based 
software system is the final deliverable, there are 
identifiable intermediate products which demonstrate progress 
to that goal. This methodology forces a prior planning 
approach to be initiated. For instance, a working electronic 
prototype is the logical product deliverable of a functional 
specification. The prototype might include one dozen screens 
and the ability to view the screens in the same relationship 
as in the final system. The deliverable schedule might have 
included the completion of two electronic screens per week. 
Difficulty in agreement with a screen format would appear as 
a delay in completion of the particular electronic screen in 
question. By identifying the specific delay point the system 
development staff avoids appearing unaware of the schedule 
and can more effectively identify delay points. These delays 
are not of themselves a software problem. 
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Post Development Control 


The majority of the alternatives discussed so far have 
pertained to solutions applied during the development phase. 
To complete the discussion of effective implementation of 
DBMS software, viable mechanisms must be discussed for 
continued efeetive use. The strategic plan should continue 
as the cornerstone of the maintenance effort. As the 
development effort transitions to a close, it is imperative 
to establish specific control structures. These controls 
fall into three areas. Production software control, 
production data control, and scheduled software enhancements . 
As the system is released into the user community, changes 
will be required to satisfy the user community. In all three 
eases it is important to track adjustments in a regulated 
fashion . 

A simple but proven technique is control forms. These 
forms should detail the requested change or difficulty, a 
description of the change or difficulty, requested date, and 
description of the solution. In addition, the system 
development staff should arrange for assignment of 
responsibility and provide for management signoffs. The 
desired result is an audit trail of controlled changes. Such 
control forms are appropriate for any of these three areas. 
For legitimate scheduled enhancements, where the scheduled 
work is more than a few days, prior review approval is 
necessary before starting. 

The Space Telescope Management Information System is 
now entering this post development phase of implementation. 
Control forms for data changes, software changes, and 
enhancements have been created. Initial system changes have 
been requested and implemented. 


18 



Summary 


The purpose of this paper has been to discuss effective 
organizational solutions for implementing DBMS software. 

Paramount to this successful implementation effort is development 
of a strategic plan. For Management Information Systems 
(MIS) this is often expressed visually in an Information 
System Architecture. The purpose of this Architecture is to 
gain top mangement commitment. Most importantly, this 
strategic plan should reflect the organizations' structure. 

If the orgainization is decentralized then the information 
gathering and dissemination plan must reflect this reality. 

In the context of the Space Telescope Program this 
organization structure included the demands of an on-going 
program with the requirement to integrate diversely reported 
financial data with selected relevant technical feedback. 

The most immediate difficulty in implementati ng DBMS 
software is dealing with shifting user requirements. This 
problem was set in the context of calculated trade-offs, 
a reality for any project. Prototyping, the creation 
of an initial working system, is a powerful tool to establish 
the baseline requirement. Users are made an integral part 
of the development process in reviewing this so called 
electronic strawman. With continued development, the 
prototype continues as the vehicle for accepting change, 
reflecting the iterative nature of software. 

Another traditional problem with implementation has 
been the establishment of reliable DBMS vendor support. 

For this, techniques are less of an issue, rather the 
evaluation should center on a series of factors in which to 
make a weighted estimate. Emphasis should be concerned 
with the likely leverage the user may have in case of 
difficulty. The financial strength of the vendor should be 
examined as well as evaluation of other user sites. Other 
important considerations include, a strong user group, and 
a vendor who supplies the hardware and the DBMS. Signing a 
lease agreement may be a more powerful lever than a purchase 
agreement. The technical evaluation should ask the question, 
does the application require the degree of complexity that 
the DBMS software offers. More complexity translates to a 
longer learning time and possibly more maintenance 
di f f iculties . 


19 



As the develoment lifecycle continues, management 
considerations must continue to be supported. Although 
the prototype continues to demonstrate the development 
effort, a schedule is esssential to demonstrate progress 
against a defined timeline. Because software development 
is a recursive activity and shifting requirements are a 
reality, it has been demonstrated to be useful to identify 
intermediate deliverables. These deliverables should be 
expressed in functional terms that a general user could 
understand. This will be important because as delays are 
identified management will need to be informed. Many delays 
in implementation of DBMS software are not directly software 
related. An accurate means of identifying these sticking 
points will permit an accurate determination of the 
underlying difficulty and permit a managment decision to be 
made. Intermediate product deliverables are a form of 
development insurance. 

As development winds down, the importance of continued 
monitoring does not diminish. Continued support falls into 
three areas: prodution software control; production data 
control; and software enhancements. For all these areas a 
regulated means of tracking is essential. Production control 
forms are one such way of providing an audit trail of 
changes. These forms should include requestor, change 
requested, description of change or problem identified, 
accompanying description, and provision for approval signoff. 

The dynamics of a DBMS implementation are many. No 
technique discussed here is dificult to understand, many 
were borrowed from other fields of study. If there is one 
key it is the discipline to maintain the effort necessary to 
see the Management Information System successfully 
implemented . 
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ADMINISTRATIVE AUTOMATION IN A 
SCIENTIFIC ENVIRONMENT 


JOYCE R. JARRETT 
GODDARD SPACE FLIGHT CENTER 

One need only examine NASA's accomplishments haver its brief 25-year history to 
be assured that the talen and capability exist to accomplish virtually any tech- 
nological goal it might pursue. NASA/ Goddard Space Flight Center (GSFC) with its 
many experts, renowned scientists, and some of the most sophisticated computers 
in the world, played a major part in these accomplishments. One would think that 
a scientific environment then must be the ideal place to carry out administrative 
duties too. 

In 1981, after having worked on the administrative side of the house for many 
years, the big opportunity arose to automate a scientific directorate in the man- 
agement management of its resources, manpower, travel, Research Technology Objec- 
tives and Plans (RTOPs), physical space, etc. Again, one would think that a scien- 
tific directorate would not only be receptive to using automation for administra- 
tive functions, but would insist on it. Surprisingly, although the scientific 
personnel were advanced in the development and use of hardware and software for 
scientific applications, resistance to the use of automation or purchase of ter- 
minals, software and services, specifically for administrative functions was wide- 
spread. There was skepticism that automation would lead to more information 
gathering, more paper, extra work, loss of control, and ultimately less productiv- 
ity. The perception was that the Center had a Management Systems Office that 
was responsible for the Center administrative databases that would meet most re- 
quirements. Although there were numerous complaints about timeliness of reports, 
inability to interact with the system and admittedly, using manual calculations 
from several reports in order to provide analysis was an archaic process for these 
times; there were generally negative reactions toward efforts to improve the situ- 
ation. The following saying by Nicolo Machiavelli really seemed appropriate. 

"There is nothing more difficult to take in hand, more perilous to 
conduct, or more uncertain in its success, than to take the lead in 
the introduction of a new order of things, because the innovator has 
for enemies all those who have done well under the old conditions, 
and lukewarm defenders in those who may do well under the new." 

What does an administrative manager do when faced with this situation, a short- 
age of personnel to proceed, and ever-increasing internal management, Center 
and Headquarters requirements for information? A clue from one of the more under- 
standing scientists made sense, "you've got to show them it will work, and demon- 
strate mprovements , before you'll get scientific management support." This paper 
will highlight our approach to automating in this environment, some problems/con- 
straints, acceptance and future plans in this area. 

APPROACH/PROBLEMS AND CONSTRAINTS 


Realizing that automation would have to occur without full management commit- 
ment and using existing equipment and personnel where possible, we first 
tackled the areas that were the most labor intensive or that received the most com- 
plaints. A detailed review of the previous method of providing information 
was conducted and the problems associated with each were highlighted. The IBM 
4341 is the host for administrative computing at Goddard and terminals, 
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printers and modems of various types were available around the Center. The 
existing software was and still is the RAMIS II Data Base Management System. 
The IBM Time Sharing Option (TSO) utility was also available to allow more 
efficient use of RAMIS. 

One of the most important factors in accomplishing a job is to acquire the 
appropriately skilled and motivated personnel. With this in mind, some people 
changes and additions occurred resulting in a team of three who were not 
experts in ADP, but who had the ability to learn and possessed the right 
attitude. Training was identified and provided and contacts with ADP experts 
on the Center were established. 

Although it was difficult to obtain priority from the Center's Management 
Systems Office to have them automate our priorities, the assistance provided 
on specific technical questions was outstanding. In retrospect, although it 
took a long time and much patience, it was probably better because there now 
exists a base of knowledge from which to expand. 

Another problem was trying to find time with the heavy workload to take 
training and learn to develop programs and systems. The perception from the 
scientific side was that the administrative staff had increased and results 
were not immediate. Managers need to be aware that automation does take more 
resources initially, but the benefits in the long run far outweigh this 
initial investment. Efforts utilizing existing data as much as possible, 
developing programs that provide more valuable and useful analyses, and 
prompter reporting, have shown some skeptical managers that automation can 
improve management. The administrative staff was provided training and 
support and improvements have been made on initial attempts. As with any 
system, the bugs had to be found through use before they could be addressed 
and problems solved. 

An additional problem was data input. Improved software, full screen editors, 
increased training, contractor support and priority assistance from MSO have 
helped alleviate this problem. As user-friendly full screen data entry 
systems are developed, clerical staff will be able to provide support in this 
area. 

The increased use of CRT terminals is a significant change in the office 
environment. Based on our experience, it has become clear that ergonomic 
concerns must be addressed. Proper lighting and furniture designed to provide 
support for the worker who will spend extended periods sitting at a video 
terminal are imperative. This is part of the initial investment but will 
result in increased productivity and a healthier and more motivated staff. 

ACCEPTANCE 


Over the past several years, most of the administrative function areas that 
fell under my auspices have been automated, i.e., RTOPs, manpower, travel, 
reimbursable agreements, physical space, various inventories, etc. A clue 

from one scientist to show the scientific managers through better 

analysis, manipulation of data to suit their own desires, better and more 
timely information, elimination of paperwork, — proved correct. Although it 
took time to gain acceptance, scientific management encouraged us to present a 
Center Workshop on the Administrative databases developed for the Applications 


22 



Directorate that had Center -wide application. The Workshop was held on March 
16, 1983, with approximately 100 attendees from virtually every directorate at 
the Center. Each staff member presented the portions with which he had been 
most involved, highlighting where the requirement originated, the old method 
of obtaining the information, the new automated method and the benefits 
derived. The need for sharing information, equipment and talent where similar 
requirements exist was stressed and the response was almost overwhelming. 

From that workshop, Center needs were identified and the results were 
presented to our management who arranged for us to present our findings to the 
Deputy Director of the Center and other top management who were in a position 
to take action. In addition to sharing information and expertise, the training 
of personnel on the use of existing systems was a problem across the Center. 

Several positive things happened from those presentations. A Center 
Administrative Information Processing Planning Committee (AIPPC) was 
established with a representative from each directorate, whose mission is: 
to provide a forum for directorate administrative users to keep abreast of 
current developments in office automation technologies and to exchange 
information on use of office automation in their areas; to identify specific 
areas within the Center where office automation application can lead to 
greater efficiencies and significant manpower and cost savings; to work toward 
implementation of automated techniques in these areas and to develop a set of 
recommendations for implementing technologies, including specific 
recommendation on hardware/software purchase and use. 

A training sub-committee was established under the AIPPC whose primary 
responsibility was to identify specific training needs for the Center user 
community, to create an information exchange and to increase awareness of 
existing administrative programs and systems (hardware and software). Some 
achievements to date include publishing an ADP Assistance Directory for 
Business/Resources Applications which includes name of employee, extension, 
building and room number, type of equipment used, resource applications, and 
available software. These people volunteered to assist others and it included 
scientific as well as administrative personnel. The Committee also identified 
specific training needs and presented them to the training office which is 
resulting in additional funding for FY85« The AIPPC committee is on-going and 
is in the process of preparing a report on overall accomplishments to date. 

In our own directorate, an Applications Advisory Group for Automation of 
Administrative Functions (AAGAAF) was formed in January 1983* with a 
representative from each division — some scientists and some administrative 
personnel. The general goals of the group evolved as follows: 

• To educate ourselves on current developments in office automation 
technologies, and to exchange information on their use. 

• To identify specific areas within our area where automation of 
administrative functions can lead to greater efficiencies and 
significant manpower and cost savings, and to work towards the 
implementation of automated techniques in these areas. 

• To develop a set of recommendations for implementing new technologies, 
including specific hardware and software purchases. 
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The group met approximately onee a month and the first several meetings 
consisted of setting goals and gathering information, primarily by scheduling 
a series of speakers to report on developments in automation at Goddard Space 
Flight Center and NASA Headquarters. Subsequent meetings addressed specific 
problem areas where automated techniques would be useful. 

1. A master list of problem areas was generated and individuals or 
groups are working on solutions. 

2. An RTOP subcommittee was formed to investigate methods of reducing 
the effort spent on preparing the directorate response to the RTOP call. The 
goal was to have new procedures implemented in time for the FY85 RTOP cycle 
and the Full Screen Manager (FSM) capability is presently being used. 

3. In order to overcome perceptions that clericals are not included in 
the decision making process, a clerical subcommittee was recommended to 
identify problems related to word processing, electronic mail and office 
equipment, and to provide guidance to the clerical staff. A major 
reorganization delayed establishment of this committee. 

4. A contractor (General Software Corporation) was engaged to develop an 
inventory of directorate hardware and software and to make recommendations on 
the most cost effective way to automate and integrate our administrative 
systems (keeping in mind the Center and Agency plans). Initial thinking is 
that any system should include, at a minimum, integrated word processing, 
electronic mail and shared databases with local area networks as appropriate. 

5. All members of the committee have implemented Telemail capabilities, 
and meeting announcements and minutes are now distributed by this method. We 
identified key personnel to use Telemail and arranged for training. Efforts 
in this area have led to the introduction of Telemail capability in the 
Directorate office. We are studying possible ways to implement electronic 
mail in many areas of intra-directorate communications. 

The group has been on hold since January 1984, due to a major reorganization 
— the merging of the two scientific directorates. This makes the need even 
greater to communicate through this forum and develop strategies for an 
overall direction for administrative automation and we anticipate starting up 
soon with additional members to represent the other directorate. 

New management is already receptive and has added funds to include the second 
directorate in the Contractor's survey of equipment and software and an 
overall recommendation for a directorate strategy for administrative 
automation. Results will be presented this month. 

FUTURE DIRECTIONS ANTICIPATED IN ADMINISTRATIVE AUTOMATION 
IN THE NEW SCIENTIFIC ENVIRONMENT 


Most future plans for administrative automation within the Space and Earth 
Sciences Directorate involve the use of personal computers and applications 
that will distribute the processing among these smaller, lower price 
processors. The introduction of microcomputers to administrative dat,a 
processing has brought about several changes in the way work is carried out 
and the way information is accessed, manipulated, shared, and transferred. 
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The way microcomputers have become a part of the administrative office follows 
a logical progression. The first management applications are typically 
spreadsheet modeling and local database manipulation. This usually involves 
entering the data manually into a model or data base. This first step 
introduces the user to the computer, and the capabilities. 

Manual data entry is not efficient use of an administrator's time. This is 
especially true when the data already resides in some form on a larger 
computer system. So, the initial use for manipulating data leads to the 
desire for access to the data stored in mainframe computer data bases. 

The micro-mainframe link is the first integration of microcomputers into the 
larger data processing picture. This step is followed by two more logical and 
semi -independent changes. In the past, the mainframe systems provided a 
central location for data storage and access. Microcomputer users do not 
have a central location to store this data and if data is going to be on these 
small computers, a suitable method must be found to transfer it from place to 
place . 

This is where networking fits into future plans. As more data is distributed 
among decentralized locations, the need to share and transfer the data will 
require that networks be integrated into the work place. This is true in 
both the scientific and the administrative communities. The types and 
placement of such networks will depend on the specific needs of different 
users and the technology available. Local Area Network technology is 
developing rapidly. Still, there are a number of questions not yet answered 
in this area. 

One relative certainty is Ethernet. Ethernet will probably provide the link 
within small areas, and multiple Ethernet segments will be the links within 
single buildings. The links between Ethernet segments, linking buildings over 
longer distances, is not yet certain. This is the area where the largest 
number of changes are still to come. Much research and product development is 
occurring now to find the best way to tie Ethernet segments together over 
these longer distances. 

The use of microcomputers and local area networks provide capabilities that 
will be utilized in a variety of ways. The ability to draft papers, letters, 
and memos on a scientific or managerial work station and transfer via network 
to a clerical workstation for editing, formatting and quality printing will be 
utilized. Electronic mail will also become a standard for communications. It 
will never completely replace written mail, but it will become an accepted 
means of inter office communications. 

Another important area in which microcomputers are just beginning to assert 
their capabilites is as a method of distributing the processing loads. These 
small inexpensive processors will help take some of the processing load off 
mainframe systems. Several vendors have introduced mini -mainframe powered 
desktop systems. The IBM XT370 with RAMIS II software may at some point 
provide a low cost local system capable of mainframe processing and compatible 
with the IBM 4341 based RAMIS II. 

The use of microcomputers for the FY85 manpower exercise is another example of 
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distributed processing. Using low cost off-the-shelf software, an application 
was developed to utilize IBM Personal Computers. The application was 
developed to allow users to work on their manpower spreadsheet on the 
microcomputer. The spreadsheets were then collected from the divisions on 
diskettes, and uploaded into RAMIS directly. The application broke down to 
approximately 80% PC based processing and 20% mainframe based. This reduced 
the load on the host system, and provided both host and local system users an 
increased response time. This method was used for the first time in our newly 
combined directorates which is comprised of 752 Civil Servants and 
approximately 800 Contractors. Although this method was new to all users, 
feedback to date has all been positive. 

An important factor to recognize in planning for microcomputer integration in 
the workplace is training. These systems are a great deal easier to use than 
a mainframe system. The application software is developed with non-computer 
personnel in mind. This does not mean that we can simply put the machine on a 
users desk and walk away. Along with the commitment of funding to purchase 
the computer, we must recognize the commitment necessary to train the user and 
make this investment worthwhile. 

There are a few factors to note in this particular commitment. The first is 
that the staff requires training in the use of micro systems. Also, they 
should have access to training materials, and experienced personnel to help 
them utilize the equipment. Another factor to recognize is that while these 
systems may cost only a few thousand dollars, they provide the capabilities of 
much more expensive systems. They will also be utilized on similar 
applications as the larger systems. For these reasons, we should be aware 
that application development is an important part of maximum utilization. 

Systems analysts can be as important in utilizing microcomputer systems as 
they are in utilizing mainframe systems. A manager can spend a lot of 
valuable time learning to use a microcomputer, time that is better spent 
managing actual applications. The administrative staff should be developing 
applications to assist the manager, providing managers the data they require, 
or developing the capability to access this data without investing a great 
deal of time learning sophisticated, complicated software. 

We have set up an Administrative Data Processing room in our local area. This 
room has two microcomputers, three computer data terminals, a small software 
library, and staff to assist users in learning how to use the computers and 
the software, and to help set up applications. The cost of providing this 
assistance to the users is more than made up for in the savings in start up 
time for the staff. It also encourages users to find applications, since they 
are aware assistance is available. It helps them get over the initial 
uncertainty and fear (computer phobia) that many people experience the first 
time they use microcomputers. 


SUMMARY 

We've come a long way since 1981, but are really just beginning to scratch the 
surface. As automated systems improve, the layers of management between 
scientist and administrators will be reduced. Networking will create direct 
links between all levels of center personnel. Many improvements not forseen 
will come about as office systems develop. 
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Office automation will continue to change the way work is done for many years. 
Careful planning and commitment to integrating new systems with established 
methods will help facilitate these changes. The attitude that automation is 
done to improve a system, and not for the sake of automation is important. 

All levels of scientific and administrative staff will recognize improvements 
in a system and the success of each effort to automate will facilitate the 
next effort. Automation must be recognized as a process that occurs over 
time. 

It will take full commitment from all levels of management for resources and 
funding, on-going training and continued group efforts, greater interaction 
with the scientific community and willingness to share resources and 
technology if we hope to come close to accomplishing major administrative 
achievements and productivity increases through automation that are taken for 
granted in the scientific and technical areas. 

Finally, an assessment of administration automation in this scientific 
environment in 1984. We certainly have not obtained the "paperless office" as 
were the "buzz" words of 1980, and we're still striving for the "office of the 
future." However, the accomplishments during this period: reduction of 
paperwork and manual efforts; improved communications through telemail and 
committees; additional support staff; increased awareness at all levels on 
ergonomic concerns and the need for training; better equipment; improved ADP 
skills through experience; management commitment and an overall strategy for 
automating, gives us an excellent base to meet the upcoming challenges in 
managing resources in the largest directorate at Goddard. 
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THE ADMINISTRATIVE WINDOW INTO THE INTEGRATED DBMS 


Georgia H. Brock 
John F. Kennedy Space Center 


I. Introduction 

In parallel to the evolution of Management Information Systems 
from simple data files to complex data bases, the stand-alone 
computer systems have been migrating toward fully integrated sys- 
tems serving the work force. The next major productivity gain 
may very well be to make these highly sophisticated working level 
Data Base Management Systems (DBMS) serve all levels of management 
with reports of varying levels of detail. Most attempts by the 
DBMS development organization to provide useful information to 
management seem to bog down in the quagmire of competing working 
level requirements. Most large DBMS development organizations 
possess three to five year backlogs. Perhaps Office Automation 
is the vehicle that brings to pass the Management Information 
System that really serves management. A good office automation 
system manned by a team of facilitators seeking opportunities 
to serve end-users could go a long way toward defining a DBMS 
that serves management. 

This paper will briefly discuss the problems of the DBMS organiza- 
tion, alternative approaches to solving some of the major problems, 
a debate about problems that may have no solution, and finally 
how office automation fits into the development of the Manager's 
Management Information System. 
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II. 


What is Office Automation? 


Office automation has many facets, but the rise in administra- 
tive costs has forced industry to seek more aggressive ways of 
increasing administrative productivity just as has been done 
for decades on the assembly line. Of course, office work is 
not a well defined integrated process with measurable raw 
material and countable units of output. Therefore, the office 
productivity axiom assumes that if each office task can be 
completed faster and with more accurate information, then the 
composite . of all the tasks will result in greater overall 
productivity. Even harder to measure are the real benefits 
such as increased profitability or reduced or avoided 
expenses. At NASA, we measure productivity in terms of more 
work done by fewer people, but the amount of work is hard to 
measure. ^ Increasing launch rates are measurable, but the work 
involved in new space station challenges is hard to compute or 
even estimate. Even so, it seems logical to assume that an 
integrated office environment will produce efficiencies simi- 
lar to the integrated assembly line. The task of automating 
the office in itself has potential for increasing efficiency, 
but every facet must be carefully considered to obtain maximum 
benefit without disruption and to create an atmosphere condu— 
^bve bo the process of favorable change. Since organizations 
and people tend to resist changes that create confusion and 
chaos in the work place, a highly structured evolutionary 
process must be projected. Figure 1 depicts the many facets 
of office automation that must harmonize for the benefit of 
the organization through increased productivity. Figure 2 
focuses on the office automation environment. Figure 3 lists 
the office automation components, and Figure 4 depicts the 
office automation relationship to the total management infor- 
mation system. 
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III. Office Automation and the Large Integrated Data Base 

Management System (DBMS) 

A. The Dynamic Evolution of the Large DBMS 

It is well known that even the first computers performed sim- 
ple repetitive tasks effectively. Any process that must be 
done over and over by the same identical method is a great 
candidate for computerization. Equally important is the com- 
puter's efficient storage and recall of data. Once stored, 
information can be retrieved, sorted, and reported to high- 
light important trends that would have been lost in most manu- 
al systems. In the simplified model depicted in Figure 5, 
processing the data can be a complicated mathematical model or 
a simple procedure that manages data to support an. organiza- 
tion performing a job. The computerized mathematical algo- 
rithm is rather easy to imagine, but the simple procedure in 
support of a job can be clarified by example. For instance, 
the job of performing maintenance on computer hardware seems 
routine enough for our model of a simple procedure. Figure 6 
defines the procedure. The basic information of problem 
report number, work order number, description, and identifi- 
cation of the hardware component or part provides a history of 
work performed. Adding dates to the actions provides per- 
formance information for the maintenance technician's super- 
visor and identifies resolved problems and design changes for 
operations and design personnel. If the organization is rela- 
tively large and there are many computers operating in similar 
configurations, (e.g., the consoles supporting Shuttle vehicle 
subsystems in KSC's firing rooms), then the technician must be 
identified and the location of the hardware established. The 
operations personnel want timely data, so the simple computer- 
ized procedure becomes the on-line "Automated Line Replaceable 
Unit Tracking System." It now keeps track of the location of 
all spare parts, parts sent to the vendor for repair and 
expected due dates, etc., etc., etc. It automatically flags 
the on-line "Problem Reporting and Corrective Action System" 
when problem reports are closed. It automatically flags the 
on-line "Configuration Management Data System" when design 
changes are complete. It automatically flags the "Shuttle 
Inventory Management System" when the stock of spare computer 
parts is low. It interfaces with the "Automated Ground Opera- 
tions Scheduling System" to schedule the work and the needed 
resources. Two of the systems that are notified of signifi- 
cant events are not on the same computer. The simple proce- 
dure has quickly grown into a sophisticated integrated net- 
worked system of DBMS's that keep track of hundreds of pieces 
of information that are entered by people in different NASA 


^The systems identified in this section are not totally integrated at this time, although 
long range plans incorporate this approach. 
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and contractor organizations and are protected by elaborate 
security procedures that ensure autonomy for the authorized 
organization. Since these computer programs essentially fol- 
low the flow of procedures defined to perform work, they are 
directly affected by each change to the procedure. Even 
volume with no logical change can affect the computer 
programs. The complicated mathematical model is beginning to 
look simple and the simple procedure is beginning to look 
complicated. 

B. The Problems That Resist Solutions 

What is the simple solution to large DBMS that cannot keep up 
with the dynamic nature of work flow procedures? Can we make 
the work flow procedures less dynamic? Can we increase the 
computer resources to accomplish more timely modifications? 
Both approaches are valid but are not simple or easy in a 
large organization. 

Let's examine the approach that controls the dynamic nature of 
work flow procedures. KSC has just accomplished a major mile- 
stone along this path by combining a large number of small 
contracts into two large contracts for the base operations and 
the Shuttle processing. A possible third large contract may 
handle, cargo processing. Our model of computer maintenance in 
the firing rooms involves the first two major contractors. 
Just as the spokes in Figure 7 are reduced, the work flow 
procedures are diminished by no longer needing to separate 
each contractor's part of the job. When responsibilities are 
concentrated from five or six contractors to one contractor, 
the computer program becomes simpler. However, it must be 
changed. Along with the scramble to consolidate, KSC must 
seize the opportunity to streamline the operation. It seems 
that we may have so many changes to the procedure that the 
computer programs may need a major rewrite. In our quest for 
stable work flow procedures, we have generated a major seismic 
tremor that will send shock waves through the computer systems 
for some time. However, as with ground faults seeking equi- 
librium, a more stable future computer base is the eventual 
derivative . 

The second approach that attempts to pour more resources into 
the computer department so that modifications can be made 
quicker and easier, can certainly reduce the backlogs. Howev- 
er, a number of practical issues limit a total solution by 
using this approach. Buying major upgrades to computer sys- 
tems is a very time consuming task due partly to the govern- 
ment procurement regulations. Increasing the staff is some- 
times even harder due to the shortage of computer personnel. 
These two constraints prevent sizing the resources to equal 
the task. As Figure 8 shows, the limited resources applied to 
the requested modifications tends to flatten the need date 
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C=CONTRACTOR 



BOC=BASE OPERATIONS CONTRACTOR 
SPC=SHUTTLE PROCESSING CONTRACTOR 
CPC=CARGO PROCESSING CONTRACTOR 


INTERFACES TO THE NASA CONTRACTORS 
FIGURE 7 
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MODIFICATIONS > RESOURCES=BACKLOGS 
FIGURE 8 
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curve into an implementation curve that closely resembles the 
activations of resources curve. _ Almost all of the requested 
modifications become backlogged items. 


C. 


Where Are the Priorities - Where Should They Be? 


The computer systems that have been described are Level IV 
^ort procedures! Information from these data bases feed com- 
puterized systems at Level III (e.g., Artermis schedules) and 
Level II (e.g., "Inter-Center Problem Reporting 
Action"). Figure 9 describes the Level II, III, and IV re 
tionships. When the computer systems are down, the ability o 
ge? the job done is impacted at all levels. When the request- 
ed modifications are backlogged, the jobs take longer to pe 
form. Impact to the computerized procedure directly af e 
the productivity of the work force at each level. The dreaded 
impact to workforce productivity tends to P lace a P ri ° :i1 ' y .£ e 
modifications that benefit the work force rather than the 
modifications that benefit the managers The reports L,? the 

ed from the data bases provide data to the people who do t 
work. Reports designed to identify trends that would bewe 
ful in making management decisions are not prevalen • . 

ly, professional and technical people provide management wit 
oLl and written reports that summarize progress or identify 

problems or issues. The data bases that support the work 
force could also provide valuable information. Unfortunately, 
these reports in their current state are usually bulky _ and 
hard to interpret. Sometimes the information is scattered 
across systems and computers and is very difficult to in 
arate On top of all of these problems, they must be mailed 
or hand oarrild. Often the information is badly dated by the 
time it hits the mail drop. 


D. 


The Office Automation Alternative 


Office automation may be the answer to the modification bot 
tleneck and the awkward management reporting system. If man 
agers or their executive staffs had access to personal comput- 
ers equipped with software tools to manipulate data, and these 
tools were networked to the large DBMS, then reports could be 
tailored to the individual manager and delivered electronical 
ly to the local office printer. As the staff becomes more 
familiar with the information in the DBMS and learns more 
about the power of the tools available through the personal 
Computer a ? d hoc reports designed by the staff can generate 
timely responses to immediate requirements for lnformatio . 
By expanding the hardware and software tools, both managers 
and workers can tap the information to suit their _ needs with 
out impacting one another. Figure 10 depicts this expanded 

system. 
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INTEGRATED SHUTTLE PROCESSING DBMS 
FIGURE 9 
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NETWORKED OFFICE AUTOMATION SYSTEM 


FIGURE 10 
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IV. The Office Automation Solution 

A. Two Obstacles That Can Be Eliminated 

In order to be effective, two major problems outside the of- 
fice automation system must be solved. First, the various 
mainframes that host the large DBMS are either currently over- 
loaded or operating marginally during periods of peak utiliza- 
tion. If office automation demands are to be met, then long 
range mainframe utilization patterns need to be studied and 
adjusted to accommodate the traffic. The office automation 
system could provide central hardware that would relieve a 
portion of the loads on the mainframes. The second major 
problem that needs a solution is the outmoded KSC communica- 
tion plant. NASA and contractor personnel are concentrated in 
two major areas as defined in Figure 11. The Kennedy Switched 
Data Network (KSDN) that is currently in procurement will 
provide the communications backbone between the major build- 
ings and population centers. This system is basically a 
multiplexed twisted pair solution that will maximize the util- 
ization of the existing cable plant. It will serve the commu- 
nications requirements until growth pushes the center toward a 
fiber optics replacement. Local area networks within major 
buildings as part of the office automation system would solve 
some of the inflexibleness of the KSDN's twisted pair solu- 
tion. The current 45 day lead time required to attach end 
user equipment to a twisted pair cable plant could be elim- 
inated by providing local area network outlets in each room. 
The local area networks within buildings and the KSDN between 
buildings should network end users to any destination desired. 

B. The Goals of Office Automation 

There are a number of committees throughout NASA devoting 
their time toward achieving increased productivity through 
improved management information systems. KSC's Office Auto- 
mation Task Team chaired by Dallas Gillespie was formed in 
March 1983. Figures 12 and 13, from the February 1984, Booz , 
Allen and Hamilton "NASA Office Automation Planning Study 
Findings and Conclusions," identifies the NASA Goals and the 
NASA-wide information system steering groups. Office automa- 
tion assists in the achievement of all of these objectives. 

On the local level, KSC must improve the effectiveness of NASA 
personnel in order to meet the increasing demands of the Shut- 
tle multi-vehicle processing. Space Station planning, Shuttle/ 
Centaur modifications, and various new support requirements. 
An integrated office automation system provides for increased 
productivity through the following general objectives: 

• Provides more timely and integrated information 
access. 
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NASA GOALS 


Presented By James Beggs on March 23, 1983 


• PROVIDE FOR OUR PEOPLE A CREATIVE ENVIRONMENT AND TIIE BEST OF 
FACILITIES, SUPPORT SERVICES, AND MANAGEMENT SUPPORT SO THEY CAN 
PERFORM WITH EXCELLENCE NASA'S RESEARCH, DEVELOPMENT, MISSION, AND 
OPERATIONAL RESPONSIBILITIES. 

• MAKE THE SPACE TRANSPORTATION SYSTEM FULLY OPERATIONAL AND COST 
EFFECTIVE IN PROVIDING ROUTINE ACCESS TO SPACE FOR DOMESTIC AND 
FOREIGN, COMMERCIAL, AND GOVERNMENTAL USERS. 

• ESTABLISH A PERMANENT MANNED PRESENCE IN SPACE TO EXPAND THE 
EXPLORATION AND USE OF SPACE FOR ACTIVITIES WHICH ENHANCE THE SECURITY 
AND WELFARE OF MANKIND. 

• CONDUCT AN EFFECTIVE AND PRODUCTIVE AERONAUTICS PROGRAM THAT 
CONTRIBUTES MATERIALLY TO THE ENDURING PREEMINENCE OF U.S. CIVIL AND 
MILITARY AVIATION. 

• CONDUCT AN EFFECTIVE AND PRODUCTIVE SPACE SCIENCE PROGRAM WHICH 
EXPANDS HUMA.4 KNOWLEDGE OF THE EARTH, ITS ENVIRONMENT, THE SOLAR 
SYSTEM, AND THE UNIVERSE. 

• CONDUCT EFFECTIVE AND PRODUCTIVE SPACE APPLICATIONS AND TECHNOLOGY 
PROGRAMS WHICH CONTRIBUTE MATERIALLY TOWARD U.S. LEADERSHIP AND 
SECURITY. 

• EXPAND OPPORTUNITIES FOR U.S. PRIVATE SECTOR INVESTMENT AND 
INVOLVEMENT IN CIVIL SPACE AND SPACE-RELATED ACTIVITIES. 

• ESTABLISH NASA AS A LEADER IN THE DEVELOPMENT AND APPLICATION OF 
ADVANCED TECHNOLOGY AND MANAGEMENT PRACTICES WHICH CONTRIBUTE TO 
SIGNIFICANT INCREASES IN BOTH AGENCY AND NATIONAL PRODUCTIVITY. 


BAH, Feb. 1984 


Figure 12 




NASA-WIDE INFORMATION SYSTEM STEERING GROUPS 


Group 

Function 

OASG - Office Automation Steering Group 

Coordinates and promotes the planning and 
integration of automated technologies with 
Headquarters and NASA-wide program 
activities. The OASG has members from 
Institutional Program Offices, EIS, and PTMC. 

BIS - Electronic Information Services 
Working Group 

Exchanges information for office automation 
between centers and Headquarters. 

PITAC - Planning and Implementation 
Team for Administrative Computing 

Coordinates the development and implemen- 
tation of Agency-wide Administrative ADP 
Systems. Membership includes 
representatives of all center Administrative 
ADP Managers plus Headquarters ADP Planning, 
Management, and Resource Management Groups. 

AIMS - Action Information Management 
System Committee 

Coordinates establishment of office automa- 
tion pilots involving headquarters program 
offices and selected center groups. The 
pilots are intended to define program 
support office automation application 
requirements and specifications. 

INC - Intercenter Network Committee 

Establishes guidelines and procedures to 
ensure end-to-end interoperability and 
security of "non-NASCommunicat ion 
Networks.” This includes coordinating 
center plans for Program Support 
Communication Network gateways. 

SOAP TEAM - Strategic Office Automation 
Planning Team 

Coordinates the development of an Agency- 
wide Office Automation plan and OA tech- 
nology utilization coordination activity. 


BAH, Feb. 1984 


Figure 13 




• Improves communications between workers. 

• Implements a wide range of cost effective office 
automation technologies and applications. 

• Facilitates decision making. 

C. KSC's Approach to Office Automation 

KSC's approach toward achieving an integrated office automa- 
tion system has been to focus the activity through the Office 
Automation Task Team (OATT) which is directed by an Oversight 
Committee and the KSC Center Director. Since inception in 
March 1983, the OATT has conducted site visits of installed 
systems, reviewed the literature, canvassed the KSC community, 
consolidated the requirements, and defined the specifications. 
These specifications have been issued to industry and the NASA 
community for review and comment. The responses have been 
evaluated and the committee is currently preparing a report 
for the Oversight Committee and the Center Director. 

Practical experience with networked office automation systems 
has been obtained through a leased pilot that is networked as 
well as connected to a system of data phones in key management 
areas. A personal computer loan pool has been established to 
promote the use of automated techniques. As with most govern- 
ment and non-government organizations, KSC has previously 
spent its office automation dollars on word processors for the 
office support personnel. Now that communications networking 
for stand alone units is becoming more available, the future 
targets for increased productivity are the managers and pro- 
fessionals who account for 80% of the total office personnel 
costs. While stand alone personal computers can increase the 
productivity of this group to some extent, the timely inte- 
grated reports from the large DBMS will provide a major por- 
tion of their decision support system. 

Without listing every office automation technology that KSC 
expects to get, there have been a number of features that have 
been identified as critical to system acceptance by the KSC 
community. The office automation system must have a graphics 
package suitable for generating viewgraphs of moderate com- 
plexity, must have an integrated approach to the office sys- 
tems functions, must be user friendly and responsive, must 
have a powerful electronic mail and filing system, and must 
have a comprehensive data base manager and communications 
capability. A major goal is to provide the networking func- 
tionality to our contractor's office automation systems. 
Adequate training is viewed as a major key to user acceptance 
and system success. 
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D. Office Automation Expectations 

Integrated information (Figure 14) serving all levels of the 
work force and management is KSC ' s expectation. Planning and 
reporting are expected to shift from "anticipatory" to "on 
demand." Planning will shift from analysis to simulation. 
Reporting will shift from historical trend projections to real 
time control. Information will become more accurate, more 
detailed, and more available. People at all levels will 
become more productive. 

On the other hand, the management of expectations is a crit- 
ical success factor for office automation. How fast can new 
technologies be absorbed without disrupting the work force. 
Technology is a moving target — there will always be more 
tomorrow. There is a critical need to promote the acceptance 
of lags between the creation of technology and its implementa- 
tion and lag between commercial availability of technology and 
meaningful user absorption. The KSC implementation plan seeks 
to avoid disruption, protect investments, secure acceptance, 
justify costs, provide functionality, and prevent obsoles- 
cence. Office automation is a process rather than a project. 
The office automation user for the first time will have the 
opportunity to solve the cumbersome manual procedure through 
automated methods. As the work force experiments with the 
tools that are available through office automation, they, the 
end user, will invent the office of the future through the 
natural selection of the useful features. 
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A User View of Office Automation 

or 

The Integrated Workstation 


by 

E.R. Schmerling 


Abstract 

Although handling information is a major part of our work, the 
information we need generally exists in many different places and even 
different forms. This makes it difficult and inefficient to search for the 
needed information, to verify that it is correct (or the latest version), 
to incorporate it in our work, and to transmit it to its recipient. 
Electronic technology can greatly ease the solution of these problems, 
and can help free us from the paper chase. 

The importance of central databases will be discussed. These are 
only useful if they are kept up to date and easily accessible in an inter- 
active (query) mode rather than in “monthly reports” that may be out 
of date and have to be searched by hand. The concepts of automatic 
data capture, database management and query languages will be in- 
troduced. These concepts, however, still need good communications 
and readily available work stations to be useful. It will be shown that 
a “personal computer” is the minimal necessary work station. These 
will rapidly become as ubiquitous as the telephone, and will provide 
easy access to databases, other users, larger computers and most office 
tools. This will lead naturally to vastly improved information flow and 
the reduction of “grunt labor”. It will be shown how these concepts 
are equally valid for administrative, secretarial and scientific work. 
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1. The Paper Office 

Our offices are still run by paper: paper for communications, paper for work-orders 
and purchases, and paper for computations. Despite the increasing use of computers, 
they are still, to a large extent, centrally inaccessible. Now that terminals and small 
(personal) computers are readily available, the time has come to grow out of the 
“central computer printout” mentality and make increasing use of the on-line dis- 
tributed capabilities that have become a technical reality. The central computers have 
become a fact of life; in conjunction with the Personal Computer (PC) they can become 
a real asset. 

Using computers for communications reduces time, reduces transcription errors 
and makes computers directly available to users instead of going through the 
intermediaries generally associated with central computer facilities. 

2. Central Data Bases 

It is valuable to any large organization to have a central information pool consisting 
of the state of its business, its finances, inventories, etc. Nowadays these are increasingly 
being kept in computer memories, and dignified by the appelation of Data Bases. The 
problems we face are how the data are to be entered, how they may be retrieved, 
and how they may be kept up to date. It is clear that collecting pieces of paper 
for transmittal to key-punch operators is inefficient; it guarantees time delays and 
transcription errors. Equally, the perusal of monthly reports represents a poor way of 
retrieving information required to answer specific questions. 

3. Data Capture 

Data should be entered into the computer as close to the source as possible. There is 
no technical reason why financial data, purchase orders, manpower utilization reports, 
etc., should not be entered on a keyboard rather than a typewriter. The information 
can always be printed out in any form desired, or sent to its destination electronically. 
Some form of automatic data capture is needed to ensure that the computer databases 
are accurate and up to date, in addition to the obvious saving of several steps in the 
current procedures. An approval chain can also be set up by computer, so that the 
information is only passed on when the appropriate person signifies his assent. Editing, 
or making changes, is equally easy to do provided that the requisite procedures are set 
up, and the privileges to read and write are judiciously allocated. 
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4. Data Retrieval 

Retrieval should be immediate and on-line. This implies that the data be stored 
in an orderly way under control of a decent query language. The computer’s fingers 
should do the walking, and the user should be able to go directly to the data needed with 
a minimum of effort and computer jargon. Great strides are being made in relational 
database systems that come close to meeting real requirements in this regard and 
require a minimum of time to learn. This is where a personal computer is very useful; 
it can originate the query to a much larger system, receive a selection of data for further 
manipulation, and print out at the user’s desk an edited summary of the answers to his 
questions for further action. While the completely paperless office will undoubtedly 
remain a pipe dream for the foreseeable future, there is no question that a great 
reduction can be made in the useless and outdated information that presently clutters 
up our workplaces. 

5. Editing and text work 

The personal computer has the advantage over special purpose word processors 
that it is far more flexible. A wide variety of word processing programs is available, 
and many of these can also be tailored to the individual, whereas dedicated word 
processors are immutable. A user can select a very simple text formatter like TEXTRA, 
progress to more powerful systems like VOLKSWRITER DE LUXE, or the Wang-like 
MULTIMATE or even the clumsy but powerful WORDSTAR. Programs like SAMNA 
WORD can format multi-column text, do arithmetic and generate automatic tables 
of contents, WORDIX will hyphenate automatically. The choice is very wide, and 
the better programs can merge material taken from central or other databases via 
communications links. The PC can also format material for the very powerful programs 
like r I£X that have several hundred fonts and mathematical symbols not available on 
any word processor with a mechanical printer. 

6. Communications 

Computer mail is much more convenient than US mail and much better than playing 
telephone tag. Received via a PC, it can quickly be turned into hard copy if desired, or 
forwarded to other users. An interesting use is for multi-authored manuscripts, which 
can be bounced back and forth many times in short order until all the authors reach 
agreement. 

7. Computing 

A modern PC is, in itself, a surprisingly powerful computing tool, better than the 
machines available in most University math labs thirty years ago. However, it is clearly 
not the equal of larger machines. With a PC linked on a network, however, a user 
should be able to call on a machine appropriate to his problem. 
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8. Graphics 

A PC like the IBM-PC can generate charts and low resolution graphics suitable 
for many purposes. The Apple Macintosh and Lisa are better in this regard, and 
can easily produce a variety of graphic material. For some purposes these are not 
of sufficient resolution, and lack the more sophisticated capabilities required in a 
full-featured graphics shop. Very powerful workstations have been built that include 
such capabilities. Notable is the IRIS where quite complicated objects like the Space 
Shuttle can be represented in some detail, and individual portions rotated to examine 
clearances, sun illumination and the relative positions of portions of the payload with 
respect to the earth, sun and stars. 

Sophisticated programs for generating directly almost any conceivable color graphics 
that can be produced by a well-equipped graphics department are now available on 
mini- computers. These can be generated directly from a terminal, or a PC used as 
a terminal, and manipulated rapidly to produce the desired final result instead of 
waiting for several manual iterations. 

9. Conclusions 

A personal computer can be an important office tool if connected into other offfice 
machines and properly integrated into an office system. It has a great deal of flexibility, 
and can often be tailored to suit the tastes, work habits and requirements of the 
user. Unlike dumb terminals, there is less tendency to saturate a central computer, 
since its free-standing capabilities are available after down-loading a selection of data. 
The PC also permits the sharing of many other facilities, like larger computing power, 
sophisticated graphics programs, laser printers and communications. It can provide 
rapid access to common data bases able to provide more up-to-date information than 
printed reports. Lastly, portable computers can access the same familiar office facilites 
from anywhere in the world where a telephone connection can be made. 
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LANGLEY EXPERIENCE WITH ADABAS /NATURAL 

Andrew Swanson, Coordinator 
Chief, Business Data Systems Division (BDSD) 

Langley Research Center 

Langley has been using the ADABAS Data Base Management System, together 
with its companion software products NATURAL and COM-PLETE for a little 
over 4 years. 

I will give a brief overview of those things that are operational using 
ADABAS and where we are in further application of DBMS technology. This 
will be followed by brief talks on some specific applications, including 
some users' views. As I am sure you know, the views of users and providers 
of ADP services are not always the same regarding how good (or poor) ADP 
support really is. But I think it will be apparent that we in ADP have 
provided our customers with some new and powerful capabilities that do assist 
them in getting their jobs done more effectively. 

One of the tools we have provided is that of end-user computing. In 
addition to the broad variety of pre-formatted screens available for both 
update (data input) and reports (data query), many of our users write their 
own query programs using NATURAL. With this capability, our customers can 
often meet new requirements for data retrieval very rapidly without the 
need to involve ADP systems analysts and programmers. 

The biggest problem that I believe we inflict on our customers is our 
failure to provide consistent, and consistently good, response time for 
on-line terminals. This is due, in part, to the success we have achieved. 

It was not long ago when I could easily keep track of the dozen or so ter- 
minals that accessed our system. About a year ago, the number of terminals 
had grown to about 100. It is now more than 200 with typically two or three 
dozen on-line at any given time and peaks in the range of 50 to 60. 

Not all of these are end-user or ADP customer terminals. Use of inter- 
active terminals by the ADP staff for ongoing maintenance of COBOL programs 
and the development of new applications using both COBOL and NATURAL also 
creates heavy workloads for the system. 

We have upgraded our CPU from an IBM 4341 Model Group 11 with 4 mega- 
bytes of memory to a Model Group 12 with 12 megabytes, and we have a competi- 
tive procurement in process to obtain an even faster CPU in order to provide 
one key improvement element — making more CPU cycles available per unit 
of time. We also have an ongoing effort to tune the system to improve re- 
sponse time. This includes specific efforts to ferret out and correct inef- 
ficient programs. 

Figure 1 summarizes our principal uses of ADABAS in Administrative 
Support Systems, including both operational systems and those that are cur- 
rently in development. 
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Figure 1. LANGLEY USES OF ADABAS/ NATURAL 


• STRIP AND LOAD 

• EXTRACT DATA FROM COBOL BATCH SYSTEM FILES AND LOAD IN 
ADABAS FORMAT ONTO DISK 


• HYBRID MODE 


• ADD ADABAS FILES TO EXISTING COBOL SYSTEMS 

AND/OR REPLACE NON-DBMS FILES WITH ADABAS FILES 

0 END-USER WRITTEN NATURAL PROGRAMS 

• GET NEW REPORTS NOW INSTEAD OF WAITING FOR THE ADP SHOP 
TO DO SOMETHING 

• NEW OR REDESIGNED SYSTEMS (* = OPERATIONAL) 

• BIDDERS (SOURCE) LIST 

• PR/PO/CONTRACT TRACKING/ INFO 

• CONTRACT CLOSEOUT - DUE 7/84 

• FINANCIAL MANAGEMENT (ACCOUNTING) - DUE FOR FY86 

INVOICE/PAYMENT SUBSYSTEM - DUE 7/84 

• HUMAN RESOURCES INFORMATION SYSTEM - DUE FOR FY86 

INTEGRATED PAYROLL/PERSONNEL SYSTEM 

• TECHNICAL PAPER STATUS TRACKING 

• BUDGET PLANNING/TRACKING 

INCLUDES POP DEVELOPMENT SUPPORT 

• SUPPORT CONTRACT STATUS /STAFFING INFORMATION 

• FABRICATION DIVISION (SHOPS) SUPPORT - DUE IN 85 

- TRACKS INHOUSE AND CONTRACT STATUS, HOURS, DOLLARS 

• NEMS - AGENCY- WIDE SYSTEM 

- HEADQUARTERS-DEVELOPED USING LANGLEY COMPUTER 

• SUPPLY (INVENTORY) MANAGEMENT - DUE IN FY85 

- KEEP COBOL SYSTEM BUT USE ADABAS FILES 
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STRIP AND LOAD DATA 
by 


Richard H. Jones, Computer Systems Analyst 
Business Data Systems Division 
Mail Stop 179, Langley Research Center 
FTS 928-2721 


The Strip and Load process refers to a method of taking batch data files 
and loading these files into the ADABAS Data Base Management System (DBMS) 
for subsequent on-line query. ADABAS requires a sequential data set as input 
to the Loader Utility. For purposes of this document, we assume an IBM/MVS 
operating environment using COM-PLETE, ADABAS, and NATURAL. Other tele- 
processing monitors, such as CICS or TSO, are valid substitutes for COM-PLETE. 

You just received your new ADABAS DBMS and the primary objective is to 
quickly become productive. The initial steps to becoming productive are to 
identify a prototype system and put it on-line. The prototype system should 
be small in scale but contain the complexity of larger scale systems. Once 
the prototype system has been successfully implemented, implement next the 
system with the most immediate benefit to the organization. 

The process of defining the ADABAS data base is very simple. Most new. 

ADABAS users simply define the new ADABAS file, field for field, to look like 
their old file. This procedure will work and is sometimes appropriate; 
however, with a little effort, you can avoid the potential pitfalls of poor 
disk utilization and poor performance. If a field is a derivative of other 
fields in the record, you may not want to store the field. Fields such as 
City and State may be replaced by Zip Code, Department Name may become a 
Table File, etc. ADABAS requires fields defined as numeric to contain valid 
numeric data. It is very important to look at the data values of each field 
you include in the data base . To assume fields have certain characteristics 
is not enough; you should run frequency distributions on each field. 

One of the primary functions of a Data Base Management System is to provide 
access to the data. ADABAS provides access through fields defined as descriptors. 
Descriptors are like index catalogs in the library. Interview the proposed users 
of the system to determine how they will access the data. 

The best descriptors are unique (e.g., Social Security Number) and the 
worst descriptors are non-unique (e.g., Sex Code 'M' or 'F'. The frequency 
distribution of the data values will tell you if the field is a good 
descriptor field or not so good. If a user accesses the data based on values 
from several fields, you can define a compound descriptor/"superdescriptor . 

If a part of a field is to be used in a search, for example, purchase order 
number positions 3 and 4 represent Directorate and Division, they can be made 
into a sub-descriptor. The phonetic descriptor can be used where the exact 
spelling of an alphabetic field is uncertain. In your evaluation of descriptors 
you should compute the on-line disk storage required and justify each descriptor. 
For Strip and Load Files, liberal use of descriptors is recommended. The only 
cost is on-line disk storage. 
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When you have defined the fields to be included in the data base 
and which fields will be descriptors, it should be documented and reviewed 
with the user for final concurrence and signoff. Many misunderstandings 
and erroneous assumptions have been corrected by doing a final documented 
review with the user prior to implementation. 

Now, you are ready to define the data fields and files to the ADABAS 
DBMS. This is accomplished by using the on-line interactive data dictionary 
facility called "PREDICT." You must define each field and its attributes, 
whether it is a descriptor field, and what type of data compression. PREDICT 
will generate the loader definition statements required by the jobstream used 
to load a file to ADABAS. 

The physical field sequence of the data file to be loaded to ADABAS 
must be in the same sequence as it was defined to ADABAS. Generally, this 
requires a COBOL program to reformat your non-DBMS file to conform to the 
ADABAS file definition. The ADABAS loader utility provides a user exit 
which gives control to the programer after the data is read and before the 
data is written and can be used to format data, thus saving one pass of the 
file . 

Once the files are loaded, you can write NATURAL programs to query the 
data. NATURAL is an interactive development system designed for use with the 
ADABAS DBMS. If the user has not been trained in coding NATURAL, their basic 
requirement would be met with canned programs until such time as they are 
trained. Because these files are Strip and Load, no updating occurs. 
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NATURAL GRAPHICS 

by 

Richard H. Jones, Computer Systems Analyst 
Business Data Systems Division 
Mail Stop 179, Langley Research Center 
FTS 928-2721 


The computer graphics explosion has been fueled by the increased availability 
of graphics hardware and software offered at affordable prices. The Langley 
Research Center has been caught up in that explosion. During the past year 
Langley has increased graphics hardware and software, significantly improving the 
Center's graphics capabilities in both the scientific and the business environments. 
Two major graphics software packages, IBM's Graphical Data Display Manager (GDDM) 
and Precision Visual's DI-3000, have been acquired and placed in production here 
at the Center. This document deals only with the graphics produced by the Business 
Data Systems Division (BDSD) under the Management Operations Directorate. 

A major component in any graphics system is the graphics hardware available 
to the user community. The GDDM software package requires an IBM or IBM-compatible 
computer capable of running the System/370 Instruction Set, 327X or 8100 Tele- 
processing Control Unit, and 327X, 8775, 328X, 3800, or 4250 Terminal Output Devices. 
It is not sufficient to know what terminals and control units are supported by GDDM; 
you must also know what features and configuration supports are required. Generally 
speaking, you require programed symbols and the extended function feature. 

The installation of graphics hardware at BDSD had its problems. Equipment 
ordered with program symbol support arrived without program symbol support, causing 
some confusion and a lengthy reorder process. 

Our current graphics configuration consists of the IBM 3279 Color Display 
Station which is a tabletop high-resolution Color Cathode Ray Tube Display. The 
3279 is classified as a raster terminal with each character containing a 9x12 point 
dot matrix. For passive hard copy output we use the 3287 and 3268 Printers with 
multi-color ribbon cartridges with colors red, blue, green, and black. The 3287 
and 3268 are dot matrix Printers. 

BDSD looked at several graphics software packages and selected a combination 
of GDDM and NATURAL graphics. During the evaluation and selection period, it was 
clear that all of the graphics software packages required GDDM to drive the 3279 
terminals. Therefore, GDDM was an obvious choice without preempting any of the 
other graphics software packages should it be determined that they are required or 
desirable. The possibility exists in the future that we might acquire Precision 
Visual's DI-3000 to give us compatibility with the scientific computers in the 
Analysis and Computation Division (ACD) . A primary reason for attaining this com- 
patibility is the mass storage system which BDSD could use for storing charts and 
later outputting them to passive hard copy devices, or interacting with graphics 
hardware under the control of the Control Data Corporation Network Operating System 
(NOS) computers . 
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The software configuration required to run GDDM graphics consists of 
IBM's Advanced Communications Function-Virtual Telecommunications Access Method 
(ACF-VTAM) and IBM's Time Sharing Option (TSO) , or Virtual Machine/Conversational 
Monitor System (VM/CMS) , or Customer Information Control System (CICS) . GDDM 
currently does not function under our teleprocessing system COM-PLETE. However, 
the next release of COM-PLETE does support GDDM and the extended functions of 
the 3279 terminal. Testing will be conducted to see if graphics users and general 
query users can mutually co-exist in COM-PLETE before discontinuing TSO. 

GDDM is a base graphics product and, as such, has many adjuncts. For the 
business graphics, we selected the Interactive Chart Utility (ICU) and the 
Presentation Graphics Feature (PGF) . A significant problem in business graphics 
is the ability to present the data to the graphics software in such a format as 
to obtain the desired output graphics with little technical knowledge or effort. 

To meet this requirement, BDSD selected the NATURAL graphics software package 
marketed by Software AG of North America. 

NATURAL graphics interfaces with ADABAS, our Data Base Management System, 
at a very high level and, because we have trained over 100 employees in NATURAL 
programing, it seemed natural to acquire NATURAL for our graphics. NATURAL graphics 
has two verbs which allow graphics. They are 'PLOT' and 'DRAW'. PLOT is used to 
identify and accumulate the data points, and DRAW is used to tell the type of chart 
to draw and when to draw the chart. All of the capabilities of NATURAL are 
inherent in NATURAL graphics. 
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ASYNCHRONOUS FILE TRANSFER TO IBM PC's 


by 

Jerome Hoerger, Computer Systems Analyst 
Business Data Systems Division 
Mail Stop 179, Langley Research Center 
FTS 928-2721 


The Asynchronous File Transfer System is used for interactively selecting 
and transmitting text files from the BDSD host processor to an IBM Personal 
Computer. The IBM asynchronous communications support package is used for handling 
the communications on the Personal Computer. An application program (NATURAL, 
COBOL, etc.) is used for selecting and formatting the records to be transmitted, 
and three subroutine modules residing on the BDSD host processor are used for 
interfacing the application program and the communications software. 

Each record transmitted to the Personal Computer must be in the standard 
ASCII format as illustrated below. This record format is directly accessible by 
BASIC and many of the Personal Computer software packages provide utility programs 
for converting them to the format required for the particular package in question. 

Standard ASCII Format 


data, data, "data, data" ,dataCRLF 

In this format each data .value is separated by a comma. A data value that 
has a comma embedded within it must be enclosed within quotation marks. The record 
is terminated with a carriage return (CR) and line feed (LF) character sequence. 

Hardwar e and Software Requirements 

The following hardware and software is needed to access the BDSD host 
processor: 

IBM Personal Computer 


64 K bytes memory 

- Asynchronous Communications Adapter 

IBM Disk Operating System (DOS) and Disk BASIC 

IBM Asynchronous Communications Support Version 2.0 (modified by BDSD) 

How To Use the Asynchronous File Transfer Facility 

Prior to using the Asynchronous File Transfer Facility, a terminal specifi- 
cation for accessing the BDSD host processor must be defined. The terminal 
definition parameters must be set as follows: 
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1 - Line Bit Rate (300 or 1200) 

2 - Type of Parity Checking (Even) 

3 - Number of Stop Bits (1 Bit) 

4 - XON/XOFF Support (Absent) 

5 - Line Turnaround Char Sent to Host (XOFF) 

6 - Local or Host Character Echoing (Local) 

7 - First Character To Be Deleted (All) 

8 - Second Character To Be Deleted (LF) 

9 - Third Character To Be Deleted (XON) 

10 - Fourth Character To Be Deleted (None) 

11 - Line End Character Send by Host (CR) 

The application program is responsible for selecting and formatting the 
records making up the file to be transmitted. Each record must be terminated 
with a carriage return character (ASCII Code - OD) . Consult the Personal 
Computer documentation for restrictions on the ASCII file format. The appli- 
cation program can be written in any language supported by C0M-PLF.TE (BDSD's 
teleprocessing monitor) . 

The subroutine modules must be called by the application program to 
facilitate the file transfer. These modules are described below. 

FILEOP - The FILEOP module should be called prior to entering file capture 
mode on the Personal Computer. It sends the message READY DISK FOR FILE TRANSFER 
to the Personal Computer and waits for the operator to ready the disk and reenter 
terminal mode. After terminal mode has been entered, the operator must depress 
the return key to inform the host processor the file transfer is ready to be 
started. 

Format - CALL 'FILEOP'. (COBOL) 

CALL 'FILEOP' # DUMMY (NATURAL) 

Arguments - #DUMMY - Identifies a dummy argument required for the 

NATURAL CALL statement. 

FILEWT - The FILEWT module must be called for each record to be transmitted. 
This module converts the record passed by the application program into a format 
suitable for transmission. A line feed (LF) character is appended to the end of 
the record prior to transmission. 

Format - CALL 'FILE1VT' USING # RECORD . (COBOL) 

CALL 'FILEWT' # RECORD (NATURAL) 

Arguments - # RE CORD - Identifies the record to be transmitted. The 

maximum length is 250 characters. 

F I LECL - The FILECL module must be called after all records have been trans- 
mitted. This module sends an end-of-file character (hexadecimal 1A) and the 
message FILE TRANSMISSION COMPLETE to the Personal Computer. This message will be 
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recorded on the Personal Computer's disk but will not be included as part of 
the file due to the end-of-file indicator preceding it. When the terminal 
operator receives this message, the file capture mode on the Personal Computer 
should be ended. The operator then returns to terminal mode. 

Format - CALL 1 FILECL' . (COBOL) 

CALL 'FILECL' # DUMMY (NATURAL) 


Arguments - # DUMMY - Identifies a dummy argument required for the 
. NATURAL CALL statement. 


Sample Program - 

RESET # Q (Al) #C (Al) #CR (Al) # DUMMY (Al) 

# RECORD (A250) 

MOVE H'OD' TO #CR 
MOVE ' , ' TO #C 
MOVE H ' 7 F ' TO #Q 
CALL ' FILEOP ' # DUMMY 
READ TERM-CONF WITH DECAL 

COMPRESS #Q MAKE #Q #C DECAL #C # Q CONTACT # Q # C PHONE 
#C #Q ACCESS #Q #CR INTO #RECORD LEAVING 
NO SPACE 

CALL 'FILEWT' # RECORD 
LOOP 

CALL 'FILECL' # DUMMY 
ENC 
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STATUS TRACKING SYSTEM FOR REPORTS 


Jeanne P. Huffman 
Langley Research Center 

The program DGR03 "Status of Langley Formal Reports" was developed to aid the 
Research Information and Application Division (RIAD) in tracking the progress of NASA 
formal reports through the review cycle. 

This review cycle (Figure 1) was established by Langley Management in NACA days 
as a control for Langley's final product: its research reports. The cycle is divided 

into 5 main stages with substages in each. In the 1960's, 180 days were arbitrarily 
set as the optimum time for completion of the cycle. More recently (in the 1980's), 
management decided that the cycle could be completed in 165 days. 

Accordingly, the 165 days were allotted to the 5 stages as shown on the slide, 
beginning when the Division sets up a technical editorial committee and ending when 
Publications Branch mails the printed report. 

Mailing of the report is considered the "target date." Before the days were 
allotted to various organizations, reports could lie around for months, then typing 
and printing would have to take up the slack to meet the target date. Until the BDSD 
program was established, the Research Information and Applications Division was respon- 
sible for keeping records and calculating for every report in the system the target 
date, the number of days and the calendar dates for each stage, the number of reports 
published in a calendar year, and the total number of printed pages. In addition, 
these numbers for all the reports were averaged by hand to give average days for each 
stage every month. At the end of the year, averages were calculated for each stage 
based on the total number of reports published. With the program DGR03, clerical 
personnel from various branches in RIAD input all the data using NATURAL language 
and on-site terminals (MEMOREX 1377). Printouts are requested remotely and are deliv- 
ered by the messenger service. The usual procedure is to update each stage and request 
printouts weekly. 

The figures shown are representative of the computer printouts [raise printouts] 
but have been modified for the sake of brevity and legibility. Only one line from 
each of the six sections is shown. Figure 2 shows the papers in Editorial Review, 
which means they are in the technical review stage in the originating division. The 
Technical Editorial Committee meets and makes recommendations to the author. The 
author then revises the paper for concurrence of line management and the TEC chairper- 
son. All this is supposed to occur within 49 days. Then the paper is due in the 
Technical Editing Branch. The target date shown on the right is 165 days frcm the 
date it "left division." The information shown at the top appears on all the printout 
pages but has been omitted from the slides. 

Figure 3, "Papers in Technical Editing" is concerned mainly with the date the 
report is received in Technical Editing (TEB) and the date the author is called for 
the interview with the editor. The time allotted between these two dates is 29 days. 
The report is again charged to the author until the discussion with the editor is 
completed and final figures are prepared. When the editor has the rough draft marked 
and the final figures ready, the report goes to Technical Documentation for final 
typing (Figure 4). Again the days from "Typing received" until the report is "mailed 
to author" are the days that are counted; 23 was the number allotted here. 
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After the report is typed and the author performs the final review, the next 
stage is "Finals in Technical Editing." (Figure 5). Here the report is proofread 
for typos, then the author's corrections are incorporated and the report goes back 
to typing for final corrections. The days (7) are counted from "author copy received" 
to "shipped to Printing Control (PC)." The sample on the slide is not going to make 
the target date. 

Printing Control (Figure 6) represents the printing and mailing (distribution) 
by the Publications Branch. The time allotted for this step is 20 days. The report 
shown here was mailed about 6 weks before its target date. 

Program DGR03 next gives processing days for all reports with the number of actual 
days in each of the steps you have just seen. (Figure 7). The report is separated 
by research organization (division) and those days that exceed the allotted times 
are flagged. 

After the days for each report in each division are shown, the averages are dis- 
played (Figure 8). The averages are for all the reports in the period to date, which 
is the same as the year to date, and are computed when the reports are mailed ("mail- 
out date"). This report can be very unnerving. Many of the reports that were process- 
ed last year (a bad year) were mailed in 1984, and there have not been enough reports 
with "good" figures mailed to bring the averages down yet. 

Figure 9 gives totals, which are actual numbers of reports processed, edited, 
typed, and mailed for the year to date. 

The report summary (Figure 10) was established for the research organizations 
to enable them to see actual dates. This summary report also is divided by research 
division and distributed to the divisions monthly. RIAD highlights those reports 
that are delinquent, and the research divisions find the causes for the delays. 

This program has been an aid to RIAD in 

• eliminating manual calculation 

• providing visible data for everyone concerned with report processing 

• eliminating the need to telephone divisions when reports are delinquent 

The program can also provide information on the number of reports in any stage 
of the system at any period. This can be advantageous to compare, for example, the 
number of reports in Technical Editing for the first quarter of 1983 with the number 
for the first quarter of 1984. 

A future refinement would be the capability to give an average of the total proc- 
essing days at any stage during processing in addition to the average based on the 
reports mailed. For example, it would be desirable to know the average days in Tech- 
nical Documentation for those reports typed in CY 84. 

RIAD's use of the program would also be enhanced by having personnel with program- 
ming experience. Possibly, sane of the clericals who input now could attend classes 
in programming in NATURAL. 
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THE NBS DATA MANAGEMENT TECHNOLOGY PROGRAM 


by 

Helen M. Wood 

Institute for Computer Sciences and Technology 
National Bureau of Standards 


INTRODUCTION 


Computers, peripheral equipment and software comprise over $80 
billion in annual U.S. industry revenues. With computer 
technology proving to be a major key to increased productivity in 
all sectors of the economy, it is essential that organizations 
use the technology effectively. Rapid changes in technology 
provide additional challenge to this task. 


The Institute for Computer Sciences and Technology (ICST) at the 
National Bureau of Standards (NBS) manages a Government-wide 
program to help organizations exploit computer technology. ICST 
activities include the development of standards and guidelines, 
the provision of technical assistance to agencies, and the 
conduct of applied research. Major problem areas addressed 

include : 


• computer security 

• software engineering 

• programming languages 

• data management 

• computer graphics 

• micro-based systems 

• computer networking 

• computer storage media. 


While these topics are not mutually exclusive, they provide focus 
and orientation for projects aimed at improving the management 
and use of computer technology. This paper describe activities in 
the NBS Data Management Technology Program. 


DATA MANAGEMENT TECHNOLOGY 

Rapid increases in the costs associated with software 
development and maintenance have caused organizations to turn 
to other methods of application development, including packaged 
software, report generators and data base management systems 
(DBMSs). These alternatives, however, have not always yielded 
expected cost savings due to such factors as t 

• lack of understanding of application requirements 

• ignorance of software limitations, or 

• inadequate utilization of software capabilities. 
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The NBS Data Management Technology Program is concerned wi i-h 
helping agencies improve their management o£ data resources 
by promoting the educated use of data management tools and 
echniques . Emphasis is placed on identifying the organization's 

accessing 01 those tS d a t^ captudn „ 

activities oroduoto ^ a 3 "“hine-processible f °™- Program 
f ol lowing S areasi°^ UC ^ S a " d PlanS WiU be d ® sa ribed for \he 

• Data administration 

• Data management software 

• Database architecture 

• Data transfer and conversion. 


Data Administration 

Data administration covers a broad span of activities which rana. 

oTto^toto £ ^ n Lohr i0n h° ritiCal data tC asses sing S the 1 adequacy 
controls on highly sophisticated database technology. Y 

NBS activities in this area have concentrated on 

representations for mainten ance of standard data elements and 
® f c ? mmon Federal applications, with particular 

emphasis on geographic data codes. FIPS PUB 55, for P example 
contains over 155,000 entries providing unique codes P for 


While continuing to maintain existing standards, NBS focus in 

S«ci:: ea in 5e s ?if t ;ff- o -^ Eovl ; in ? more generIc s 

selection and i definition of their data requirements; (2) 

soft£«e for fho ap P ro P riat f such as data dictionary 

f °L^? e ?° ntrol . of data; and (3) identification of 


additional , 
integrity. 


,1 . ' ' / lUCULillbclUO 

critical requirements such as data security 


Data Management Software 


The objective of 
management of va 
development of (l) s 
systems, including 
and (2) guidance 
network or relationa 
more traditional (e. 
and risks inherent 
considered . 


activities in this area is to improve the 
iluable information resources through the 
standard specifications for critical software 
DBMSs and Data Dictionary Systems (DDSs) ; 
on choosing from among alternatives such as 
1 DBMSs, file management-type systems, and 
g., COBOL-based) approaches. Opportunities 
m the use of micro-based DBMSs are also 


Fede?a? Se 5^ th ere are n ° existin 9 international, national, or 
database standards. However, proposals are currently 
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under critical review within the American National Standards 
Institute Committee X3H2. These proposals specify structures and 
operations for the network and relational data models, called the 
Network Data Language (NDL) and Relational Data Language (RDL) . 
The structures and operations specified are typical of existing 
capabilities in a wide variety of DBMS products. Thus, the 
proposed languages can be used for comparison purposes in DBMS 
selections, even before the existence of conforming products. A 
recent NBS report describes these data models and discusses how 
they might be used in the selection of DBMSs. 

NBS has developed draft technical specifications for data 
dictionary systems. These specifications have been reviewed by a 
wide range of Federal agency representatives, private industry 
users, and software suppliers and, in addition, have been adopted 
by ANSI Technical Committee X3H4 as a base document for the 
planned standard information resource dictionary system. 
Preliminary cost-benefit studies estimate that the Government 
could realize over $120 million in benefits by the early 1990's 
from the use of a standard DDS. 


Database Architecture 

Activities in this area are aimed at (1) the selection and use of 
data design methods and tools, and (2) guidance for managing the 
performance of data management systems. 

A guide to good practice in logical database design is under 
development. This report describes a recommended methodology for 
identifying and capturing critical data and relationships among 
those data, independent of the software and hardware environment. 
Emphasis is on support by a data dictionary system, graphic 
presentation for ease of understanding and validation, and the 
use of normalization for quality control. 

The second project is concerned with helping users select from 
among such alternatives as database machines, minicomputer, and 
microcomputer-based DBMSs. Emphasis is on hardware, not software, 
with the objective being to provide guidance on making a good 
first-cut at hardware selection for a DBMS application. 
A benchmark-based approach has been used, involving records 
extracted from the central civilian personnel database maintained 
by the Office of Personnel Management. Two reports are planned: 
one describing a comprehensive benchmark methodology for use on 
database systems, and the other summarizing the methodology and 
presenting the results of the benchmark experiments conducted. 


Data Transfer and Conversion 

Transporting a database between systems is typically costly and 
time-consuming. Standard data models (e.g., the NDL and RDL 
activities described above) , along with standard formats for 
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data interchange, can significantly reduce the expenses 
associated with both data transfer and conversion. Furthermore 
such standards can smooth the way to truly distributed database 
environments . 

A recent NBS report describes approaches to database translation, 
discusses candidate interchange forms, and recommends a method 
for representing the data structures of the proposed NDL and RDL 
specifications in a form suitable for database interchange. 


CONCLUDING REMARKS 

The NBS Data Management Technology Program addresses major 
problems encountered during the following stages of an 
application's lifetime: requirements analysis and database 
design, system selection and implementation, operations 
management and conversion. Products developed include standard 
software specifications, guides to "best practice," standard data 
elements and representations, and reports documenting the 
experiences of other organizations as they attempt to improve the 
management of their computing resources. 

Database Laboratory facilities are maintained for the 
investigation and analysis of state-of-the-art database 
technology. These facilities support collaborative testing with 
researchers, vendors, users, and standards developers. 

A Federal Data Management Users Group has been established by 
NBS to foster technical information exchange and to aid NBS in 
the identification of Federal needs. This users group meets 
quarterly at NBS. 

Additional information and a list of reports, standards, and 
guidelines published by this program can be obtained by 
contacting: 


NBS Data Management Technology Program 
National Bureau of Standards 
A255 Technology Building 
Washington, D.C. 20234 
(301) 921-3553 
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DATA COMMUNICATION 


BETWEEN DATA TERMINAL EQUIPMENT AND THE JPL ADMINISTRATIVE 

DATA BASE MANAGEMENT SYSTEM 
BY 

ROBERT W. IVERSON 


INTRODUCTION 


Scope 

This paper discusses approaches to enabling an installed base of 
mixed data terminal equipment to access a data base management 
system designed to work with a specific terminal. The approach 
taken by the Jet Propulsion Laboratory and our experiences to 
date are described. 

Background information on the Jet Propulsion Laboratory (JPL) , 
its organization and a description of our Administrative Data 
Base Management System is included. 

Background 

The data base management system need of JPL is unique amoung the 
NASA Centers. JPL is an operating division of the California 
Institute of Technology (Caltech). Caltech/JPL performs research, 
development and other related activies under contract with NASA 
using facilities provided by the government. The Caltech/JPL 
contract requires NASA standard administrative and financial 
reporting. However, the design and operation of the internal JPL 
management and administrative support systems are the responsibi- 
lity of Caltech. 

JPL is organized as a matrix, Projects and tasks are formed and 
funded within the Program offices as required and approved by 
NASA. The work is performed by the Technical Divisions in 
accordance with the requirements and guidelines established by 
the Program and Project offices. Financial, Procurement, 
Personnel and other administrative support is provided by the the 
Administrative Divisions. 

Some large Planetary research and development projects currently 
being managed by JPL include the VOYAGER, GALILEO and IRAS 
Projects . 
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COMPUTING AND INFORMATION SERVICES 


THE CISSP 

In 1983/ the Computing end Information Services System Project 
(CISSP) was formed with the primary objective of developing and 
adopting up-to-date computing /networking, and information 
services technology to meet the future data processing and data 
management requirements of JPL. The CISSP is comprised of two 
parts: 

Development of a computer-communications network called the 
Technical and Administrative Computer Communications Network 
(TACCN) . 

The upgrade of JPL's Management and Administrative Support 
Systems, (MASS) the systems and data which support the 
management and administration of the laboratory. 

The use of the TACCN to provide user access to the MASS is the 
subject of this paper. 

THE MASS 


The previous administrative support systems at JPL have been 
developed ad— hoc and uncoupled. Our Resource management. 
Procurement, Inventory, Cost accounting. Payroll and similar 
systems have operated in a stand-alone, batch, labor intensive 
environement . 


In 1982, plans for an integrated, interactive Management and 
Administrative Support System (MASS) were developed and 
implementation of this system was started in 1983 with the 
establishment of the CISS Project and the procurement of a 
generalized data base management system. A IBM 3083 Computer was 
procured early in 1984 to host this system. 

The overall implementation precept for the MASS is to procure 
commercially available applications software wherever possable. 
One of the foundations of this precept is the use of a commercial 
generalized data base management system. The Integrated Database 
Management System (IDMS) by the Cullinet Corporation was selected 
as this foundation. The selection of IDMS dictates a set of 
applications which can be purchsed to perform MASS functions. 
The commercial availability of applications compatable with the 
Cullinet IDMS determines the order in which the JPL systems will 
be implemented. A characterization of the target applications of 
MASS when all elements have been completed is shown in figure 1. 
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FIGURE 1 
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TACCN 


The TACCN is being developed concurently in 
The major elements of the TACCN are shown in 
include: 


support of the MASS, 
figure 2. These 


* The IBM 3083 Computing System which hosts the MASS software. 

* Institutional Local Area Network ( I LAN ) which provides 
reliable high speed data communications between terminals, 
trom terminal to computer and computer to computer. 

* File and print servers on the network. 

Electronic message store and forward services. 

* Office Automation services 

Science and Engineering computing services. 

* Flight Project Support Services 


THE DATA COMMUNICATION ENVIRONMENT 


THE I LAN 


^u 1 p f 0Vlde the Primary data communications functions 
h . co ,, the laboratory. The I LAN uses Broadband technology and is 

comofnv and ?° ftwar ® Purchased from the Ungerman-Bass 

innn any * Ifc provide on line data communications for over 

^ d M lt iS nall m , 1 dial comm unications facilities will be 

h ia B ; Talecomm Digital Telephone central office 

provided by Pacific Telephone Co. 

Il? e TnT are mu Urrently 0Ver 1500 Data Terminal Equipment (DTE) units 
at JPL There are over 100 separate models o? types of DTE which 

MaQQ ^K Ser « ed by the ILAN and the MASS * The major users of the 

Divisions 6 an^° 9 £h m m nd K ? ro ? ect . Office, The Administrative 
™ i and th< r Technical Division Management) use Micro 
computer workstations (IBM PC/XT), Word Processors (WANG), 
Executive desk sets (Northern Telecomm Display Phone), and 
Portable hardcopy terminals such as the TI Silent 700's. 


84 



FIGURE 2 



FIGURE 2- ELEMENTS OF TEE TECFMCAL /C1M1NISTRATI\E CXF'F’UTING WD COMMUNICATIONS NETWORK 

(TACCN) 
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THE MASS/TERMINAL INTERFACE 

Xd e ally , ali terminals connected to the MASS/IDMS/IBM 3083 would 
*?® 3278 terminals (or their equivalent) , each operating at 

9600 bps allowing the transmittal and receipt of a complete CRT 
screen in one second. However/ because JPL's inventory of 
terminals includes only about 30 IBM 3278 terminals it is 
nessesary to find ways to either adapt the non-compa table 
terminals to the MASS communication environment or to adapt the 
MASS environment to over 100 different types of terminals. The 
later option would violate the fundimental precept of a 

commercial generalized database management system and 
applications. 

Effective use of the large inventory of DTE will require one or 
more of the following work-arounds: 

* Install IBM 3278 emulator hardware or software in the 
Micro-computer based terminals and connect them to a IBM 
327x controller via coax cables. 

* Install IBM 327 X controller emulation in the Micro— computer 
terminals to allow direct host connection via the ILAN. 

* Replace 327X controlers with protocol converters to 
allow asynchronous devices to operate in the MASS/IBM 
327X/SDLC environment. 

Possible configurations of these options are shown in figure 3. 

The first two options are attractive for IBM PC's or their 
clones. We plan to use emulators where possible. The 
availability of commercial emulation packages for other micro- 
computers is uncertain at this time. 
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FIGURE 3 



FIGLRE 3 AFIFRNATIME METHODS OF PROVIDING A IBM 327X/SNA ENMRQ'^^ENT 
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Two protocol translators purchased from the Renex Corporation 
have been installed at JPL for evaluation. The Renex Translator 
display system interfaces with the IBM communications processor 
in exactly the same manner as an IBM 327X control unit. The host 
thinks that the Translator is a 327X and communicates with it in 
the same manner. Asynchronous terminals connect to the 
Translator which has control over the data and cursor positionina 
at the terminal. ^ 

According to the Renex Corporation, almost any asynchronous ASCII 
terminal which can operate in the full duplex, character mode and 
which has an addressable cursor can be supported by the 
translator. It optionaly supports Keyboard Send/Receive (KSR) 
printers such as the TI silent 700 »s for both line by line and 
lull screen applications. However, invoking some 3278 functions 
such as screen refresh on a KSR will cause all 24 lines to be 
!w^ ed ^ t 1 _ 300 baud this may take a while). There is a set of 
PROM s which are available for installation in the translator 
which supports most commonly used terminals. 

The JPL experience to date with the protocol translator approach 
has been mixed. The protocol translation function appears to 
work as advertised except for some KSR terminals. The desired 
MASS environment should allow for data file upload and download 
and this capability is not available for many terminal types. 

CONCLUSION 

The objective of the Computing and Information Services System 
Project is to provide up-to-date computing, networking and 
Information services technology at JPL. This includes an 
integrated, interactive Management and Administrative Support 
System utilizing commercially available data base management and 
applications software compatable with the IBM System Network 
Architecture (SNA) . Our capital investment in a large inventory 
• n ° n “ SNA terminals requires some temporary work-arounds which 
include use of protocol translators. The use of a error free 
data communications system (the I LAN) and 327X emulators in or 
near the micro-computer based equipment will provide a longer 
term solutions while allowing flexibility in the replacement of 
the older equipment as it becomes obsolete. 
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NASA METROLOGY INFORMATION SYSTEM - A NEMS SUBSYSTEM 


Earl S. German, Jr., and Frederick A. Kern 
Langley Research Center 

and 

Rick Yow and Ellen Peterson 
Planning Research Corporation 


ABSTRACT 

The NASA Metrology Information Systems (NMIS) is being developed as a 
standardized tool in managing the NASA field Centers' instrument calibration 
programs. This system, as defined by the NASA Metrology and Calibration 
Workshop, will function as a subsystem of the newly developed NASA Equipment 
Management System (NEMS) . The Metrology Information System is designed to 
utilize and update applicable NEMS data fields for controlled property and to 
function as a stand alone system for noncontrolled property. The NMIS pro- 
vides automatic instrument calibration recall control, instrument historical 
performance data storage and analysis, calibration and repair labor and parts 
cost data, and instrument user and location data. Nineteen standardized 
reports have been developed to analyze calibration system operations. 


INTRODUCTION 

The National Aeronautics and Space Administration has conducted an annual 
workshop on metrology and calibration since 1977. The objectives of these 
workshops were to ensure effective support for NASA's technical programs, to 
identify areas where greater efficiency and economy could be achieved, and to 
provide a unification of field Center objectives and responsibilities. The 
workshops, under the sponsorship of NASA Headquarters' Office of Chief 
Engineer, included representatives from Headquarters, each field Center, 
support service contractors, and invited guests from other agencies such as 
the National Bureau of Standards and the Department of Defense. For the past 
2 years the workshop has been held in conjunction with the Department of 
Energy's Standards Laboratories Manager's Conference. 

The activities of these workshops have resulted in: (1) A unification 

of responsibilities and objectives through the development of an agency-wide 
management instruction, NMI 5330.9; (2) the development of a document describ- 
ing the calibration capabilities of each Center; (3) an increase in the level 
of communications between Center metrologists concerning management techniques, 
calibration techniques, hardware, automatic calibration systems, software, and 
procedures; (4) NASA— wide labels for calibration, limited calibration and 
standards identification; and (5) the utilization and sharing of calibration 
resources between government agencies. However, the individual Center's 


89 



metrology programs still had significant dxf f erences— - particularly in the 
procedures used to track instrument calibration histories, manpower usage, 
and calibration laboratory performance. For example. Center metrology 
programs ranged from the simple instrument calibration with minimal documen- 
tation and no instrument recall program to a system containing several thousand 
instruments in recall and a sophisticated instrument and calibration laboratory 
performance documentation system. 

Since 1979, the Supply and Equipment Management Branch of NASA Headquarters 
has briefed each workshop on the NASA Equipment Management System (NEMS) being 
developed for agency-wide use. During the development, several standard data 
elements, which are output products of the calibration laboratory, were defined 
and installed in NEMS. However, these elements did not provide the Center 
metrologist with all the data required to evaluate calibration laboratory 
performance, metrology system efficiency, and instrument performance. During 
the sixth workshop held at the Johnson Space Center in October 1982, the 
group made the decision to develop a NASA-wide computerized management and 
information system designed specifically to support the field Centers' 
calibration programs. Since the NEMS contained a number of data elements 
required by the Center metrologists , this agency-wide system would be developed 
as a subsystem of NEMS. The first planning and development meeting was held 
at the Kennedy Space Center in February 1983, with the objective to define 
the core data elements required for the subsystem. From a review of the NEMS 
data elements, 25 elements were identified as required (fig. 1). Twelve 
additional data elements (fig. 2) unique to the subsystem were developed. A 
second meeting was held at the Jet Propulsion Laboratory in April 1983, to 
finalize core data elements, data element definitions, input document elements, 
and to begin to define output reports required. The Langley Research Center 
was selected as the lead Center to develop this subsystem with funding 
provided in July 1983, and program analyst and programer contracted for in 
October 1983. 


DESCRIPTION OF SYSTEM 

The NASA Metrology Information System (NMIS) is an agency-wide automated 
data processing system designed to improve the field Centers' instrument 
service programs, provide for automatic calibration recall of all or selected 
instruments, and to standardize the data base necessary to support and evaluate 
the effectiveness of these programs. Although the NMIS is designed to 
function as a subsystem of the NEMS, it can function as a stand alone system 
if necessary. The data base necessary to track, report, and summarize both 
instrument historical and metrology system performance is maintained under 
the ADABAS Data Base Management System (DBMS) . The software is written in 
NATURAL, the ADABAS on-line interactive processing language, and COM-PLETE, 
a teleprocessing monitor, which allows the user additional flexibility for 
ad hoc data query capability. The NMIS has been designed to operate on the 
IBM 4341 OS/MVS compatible computer. The system uses either the IBM 3270 
protocol terminal or an IBM personal computer for performing on-line trans- 
actions, conducting ad hoc inquiries, and other system operations. These 
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terminals will reside in the field Centers’ Metrology Control Center which 
will be responsible for general data entry, report generation, software 
control, backup and error recovery, and metrology system data flow. The NMIS 
transaction processing is designed to pre-edit the input data entered through 
formatted screen displays and then use this data to update the data base. 

There are 26 transactions developed to add records, modify, or delete records 
in the data base. Each transaction has data elements and/or table entries 
which are either mandatory, optional, or not applicable, while other data 
elements are automatically generated. 

The NMIS provides users with statistical summary performance reports, 
status reports of metrology related NASA controlled and noncontrolled instru- 
ments, and reports for monitoring the metrology system activities. These 
28 reports are either generated automatically on a scheduled basis ranging 
from daily to annually or on-request only. 

The majority of instruments that will normally be contained in the NMIS 
will be identified using the NEMS Equipment Control Number (ECN) . However, 
ma ny noncontrolled instruments must also be controlled by the NMIS. Identifi- 
cation of these instruments will be accomplished using a vinyl Metrology 
Control tag, similar to the NASA ECN, which is 1.35 x 0.6 inches in size. 

The tag (fig. 3) displays both the easily readable six character number, 

C00138 for example, and its equivalent bar code in a three of nine format. 


METROLOGY CONTROL DOCUMENT 

Since the field Centers' metrology programs have developed independently 
according to the specific missions, operational procedures and supporting 
documentation such as instrument work orders and on-site shipping forms are 
necessarily different. In order for the NMIS to function on an agency-wide 
level, certain segments of the Centers' procedures and documentation must 
be standardized. During two meetings held at the Kennedy Space Center 
and the Jet Propulsion Laboratory in 1983, a single form was conceptually 
developed and agreed upon by the participants. During the development of the 
NMIS Design Document, this Metrology Control Document (figs. 4, 5, and 6) was 
further developed to satisfy specific data element requirements for the 
instrument history and performance analysis reports. 

This form consists of five sections. The user information section and 
the background information section are computer preprinted from data in the 
NMIS data base. The background information section contains labor, parts, 
and outside service cost data. Most important, however, is the condition 
received" and "action taken" blocks which list the codes for the last X 
times serviced up to a maximum of eight times. This will allow the 
Metrologist to easily identify an instrument which is either unstable, mis- 
applied, or used in an environment which could be degrading the performance. 
The user-technical monitor area section provides instructions and technical 
approval for the required work. The calibration— repair inf ormation 
section contains data blocks which are completed by the personnel of 
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the performing organization. This data will be entered into the NMIS when 
the service work is completed. The local data section provides an area for 
use by the individual Centers to satisfy requirements particular to their 
metrology programs only. The reverse side of the Metrology Control Document 
is used by the performing organization to enter specific instrument service 
data as required by the individual Center's documentation procedures. 


TABLES 

The NMIS contains seven tables (fig. 7) that are unique to the system 
while utilizing five NEMS tables. These tables are used to provide necessary 
data for updating transactions and generating reports. Each table has a 
data element in the NEMS and/or NMIS equipment files as its key. A brief 
description of each table follows. 

Table 20, Recall Identification Table (fig. 8), provides the keys to 
identify instruments according to a predetermined instrument classification. 
For example, standards are classified as Reference Standard (R) , Transfer 
Standard (T) , and Working Standard (W) . In Situ Calibration (I) identifies 
those instruments requiring testing in the facility as opposed to those 
requiring calibration (C) in the laboratory. 

Table 30, Condition Received Table (fig. 9), defines the operating 
condition of the equipment received by the performing organization. Analysis 
of this type of data provides information needed to adjust instrument recall 
calibration intervals and evaluate the overall effectiveness of a Center's 
metrology program. The codes A to I were developed from a consensus of the 
NASA Centers representatives. Codes J to Z allow the individual Centers to 
define condition codes unique to their Center's operation. 

Table 45, Action Requested Table (fig. 10), defines the instrument service 
requested by the user. Codes A to J were required by the majority of the 
Centers and codes K to Z provide for service requests that are unique to the 
individual Center's operation. 

Table 50, Action Taken Table (fig. 11), defines the actions that were 
actually performed in completing the instrument service. This list of codes 
is very detailed and currently provides for only one Center unique code. 

This data enables detailed analyses of the structure of the work performed 
by the performing organization. 

Tabie 50, Measurement Discipline Table (fig. 12), defines 13 work 
discipline areas into which work is divided. Codes N to Z are provided to 
allow the individual Centers to add disciplines that are unique to their 
operations. This data will allow for detailed analyses of the workload 
according to measurement disciplines. 
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Table 75, Performing Organization Table (fig. 13), provides identification 
of the organization performing the work. For example, Code E identifies that 
work was performed on a Center's Reference Standards by the National Bureau of 
Standards as opposed to those sent to a standards laboratory (Code D) , or 
another government laboratory (Code G) . Codes I to Z are established as Center 
unique to allow Centers having more than one identifiable calibration 
laboratory to track individual performing organization performance. For 
example, LaRC has eight organizations performing such work. This table also 
includes calibration and repair labor rates for each of the codes to calculate 
instrument and calibration repair costs. 

Table 420, Transaction Number Table (fig. 14), lists the transaction codes 
identified for the operation of the NMIS. 

The NEMS contains five tables used by the NMIS (fig. 15). However, 
since the NMIS will not have a centralized data base, Table 252, NASA 
Installation Number Table, will not be significant. 

Table 40, Manufacturer's Code Table, contains codes assigned in the 
Federal Cataloging Handbooks, H-4 series, identifying each manufacturer. 
Additionally the code "XXXXX" is used when the manufacturer is known but the 
code needs to be assigned and the code "ZZZZZ" is used when the manufacturer 
is unknown. 

Table 78, Custodian Account Number Table, contains the property custodian 
account numbers and custodian numbers, names, mail codes, and organizational 
codes required for property management. 

Table 90, User Number Table, contains user numbers and names for 
employees at each Center. Some Centers' table 90 will also contain names of 
contractor employees . 

Table 102, Building Number Table, contains the numbers and names of 
buildings where equipment is located. 


NMIS REPORTS 

Through a coordinated effort of the workshop, 18 reports (fig. 16) were 
developed to monitor instrument and calibration laboratory performance. 

Since the detailed development began in October 1983, 10 additional reports 
(fig. 17) have been developed. The frequency of individual issuance, 
determined by consensus of projected Center usage, varies from a daily 
generation to a yearly generation with nine reports issued by request only. 
Additionally, if the standard frequency report issuance schedule does not 
meet a particular Center's needs, provisions are made to easily change 
the frequency. 

A brief description of each report follows. 
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. jjCjLCa libration Master List (Report 001) .- This report lists, in 
Equipment Control Number (ECN) sequence, all instruments contained in NMIS. 
Each record shows ECN, item name, manufacturer's name, model number, date 
calibration due, measurement discipline, performing organization for last 
service, and recall identifier. Report prints total number of line items. 
This report is generated quarterly and has no other selection criteria. 


- ^lib^ti on U ser List - ECN Sequence (Report 002) .- This report lists 
all instruments m the system sequenced by custodian account number, user 
number, and ECN. Each record lists ECN, item name, manufacturer's name, 
model number, date NASA acquired, calibration interval, date calibration due, 
last eight condition received codes, measurement discipline, performing orga- 
nization for last service, and recall identifier. This report provides the 
total number of instruments in each user account, each custodian account, and 
the grand total. Other report selection criteria provided include user number 
and custodian account number. 


Calibration Us er List - Item Name Sequence (Report 003) .- This report 
contains the same data as Report 002. However, it is sequenced by item name 
manufacturer s name, and model number as opposed to the ECN sequence of 
Report 002. This report is issued on request only. No other selection 
criteria is provided. 


C altbration Item Name List (Report 004) .- This report sequences the instru- 
ments m the NMIS by item name and list manufacturer's name, model number, date 
NASA acquired, ECN, custodian account number, user name, calibration interval, 
last eight condition received codes, recall identifier, and date calibration 
due. Additional selection criteria include item name, item name - manufacturer's 
name, and item name - manufacturer's name - model number. This report lists 
the total number of named instruments for each manufacturer, the total number 
of named instruments and the grand total number of instruments. This report 
is issued annually. 

-^- a .l^b rat i°n Model Nu m ber List (Report 005) .- This report lists instruments 
sequenced by model number, manufacturer's name, item name, and ECN. It 
contains manufacturer's name, item name, ECN, date NASA acquired, cost, 
custodian account number, user number, calibration interval, last eight 
condition received codes, recall identifier code, and date calibration due. 
Additional selection criteria include manufacturer's model number, 
manufacturer's name and manufacturer's name - model number. It lists the 
total number of instruments for each model number and the grand total number 
of instruments. This report is issued on request only. 

jLfA ibra tip n Dua __Lj;St - ECN Sequence (Report 006) .- This report lists by 
custodian account number and user number those instruments due for calibration 
and can be used as a calibration recall notice (fig. 18). The report is 
sequenced by each custodian account and user number, date calibration due, and 
ECN. This report contains item name, manufacturer's name, model number, 
calibration interval, measurement discipline, and performing organization. 

The report lists the total number of instruments due for each date, the total 
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number of instruments by both user and custodian account numbers and the grand 
total number of instruments due for calibration. Additional selection criteria 
include date calibration due, date calibration due - custodian account number, 
date calibration due - custodian account number - user number. This report is 
issued monthly. 

Calibration Due List - Item Name Sequence (Report 007) .- This report 
contains the same information as Report 006. However, it is also sequenced 
by item name for each custodian account number and user number. The 
additional section criteria is identical to that of Report 006. This report 
is issued on request only. 

Calibration Due List - Performing Organization Sequence (Report 008) .- This 
report lists the instruments due for calibration by performing organization 
and is intended to be primarily used by performing organization managers. This 
report is sequenced by performing organization, measurement discipline, item 
name, date calibration due, manufacturer's name, and model number. The report 
also lists ECN and calibration interval. Additional selection criteria are 
date calibration due and performing organization - date calibration due. This 
report is issued monthly. 

Calibration Overdue List (Report 009) .- This report lists those instruments 
which have not been submitted by a specified date and are overdue for calibration. 
The report is sequenced by custodian account number, user number, date calibra- 
tion due, and ECN. It contains the same information as Report 007. It lists 
the total number of items overdue by user number, custodian account number, 
and the grand total number of items overdue. Additional selection criteria 
include custodian account number - date calibration due and user number - 
date calibration due. This report is issued monthly. 

Performing Organization — Due/Overdue Status Report (Report 010) .- This 
report lists the instruments that have not been completed by a specified date. 

This report is sequenced by performing organization, measurement discipline, 
date required, and ECN. It also provides manufacturer's name and model number. 
The report lists total instruments due for a given date, the total instruments 
due/overdue for each measurement discipline and for each performing 
organization. There is no other selection criteria. This report is issued on 
a daily basis. 

Hold Status Report (Report Oil) .- This report lists those instruments which 
are not being actively processed in the performing organization's laboratory 
for such reasons as shipped for off-site repair or awaiting repair parts. 

This report is sequenced by performing organization, transaction date, and ECN. 
The report lists item name, manufacturer's name, model number, measurement 
discipline, and action taken code from Table 50. The report provides total 
number of items for each transaction date, performing organization, and the 
grand total number of items in the hold status. The additional selection 
criteria is by performing organization. This report is issued monthly. 
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Calibration Support Ana lysis (Report 012 ).- This report provides a total 
calibration and repair cost analysis in a year-to-date format and is sequenced 
by custodian account number, user number, job order number, and ECN. Data 
provided in this report include item name, labor costs, parts cost, outside 
service cost, total cost, and date instrument was last serviced. The report 
provides total cost by user number, custodian account number, and grand total 
costs for each category. Additional selection criteria is by job order, 
custodian account number, and user number. This report is issued annually. 

Calibra ti on Life Cycle Cost Analysis (Report 013) .- This report provides 
total service costs to date for each instrument. The report is sequenced by 
item name, manufacturer’s name, model number, and ECN. Data listed include 
date NASA acquired, cost of item, labor cost, parts cost, outside service cost, 
total cost, and average annual cost. Additional selection criteria include 
item name - date NASA acquired, item name - manufacturer’s name - date NASA 
acquired, item name - manufacturer’s name - date NASA acquired, item name - 
manufacturer's name - model number - date NASA acquired, and date NASA 
acquired - all. This report is issued annually. 

Production Analysis (Report 014) .- This report provides manpower data 
required for calibration, repair, and total service in hours to the nearest 
0.1 hours. The report is sequenced by performing organization, measurement 
discipline, item name, and model number. The report includes technician 
identifier, ECN, manufacturer's name, calibration hours, repair hours, total 
service hours, and date last serviced. The report provides both total hours 
and total items by measurement discipline and performing organization. 
Additional selection criteria is by performing organization. This report is 
issued monthly. 


Calibration Weekl y Statu s Re port (Report 015 ).— This report provides the 
listing of the total number of items completed sequenced by performing 
organization, measurement discipline, and ECN. The report lists manufacturer's 
name, model number, initiate date, date calibrated, date last serviced, 
action taken, and days late. The report provides, by performing organization, 
the total number of items completed, the total number and percent of items 
completed within a specified time frame. Additional selection sequence is by 
performing organization only. This report is issued weekly. 

^ Calibr ation Maintenance Time Analysis (Report 016) .— This report provides 
data describing the manpower required to service instruments sequenced by 
manufacturer s name and model number. This report lists total instruments 
calibrated, repaired, serviced; total calibration, repair and service hours; 
and average calibration, repair, and service hours. The report also lists the 
totals for these categories for each instrument manufacturer. Additional 
selection criteria is by manufacturer's name, and manufacturer's name - model 
number. This report is issued annually. 
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Out of Tolerance and Inoperative Inst rume nt Re p ort (017).- This report 
lists the instruments that were received in the calibration laboratory and 
coded B, C, D, E, F, or G from the Condition Received Table (Table 30). This 
report is sequenced by custodian account number, user number, condition 
received code, item name, manufacturer's name, and model number. Other data 
listed includes ECN, date NASA acquired, calibration interval, last eight 
condition received codes, date calibrated, measurement discipline, and performing 
organization for last service. This report lists the total number of out-of- 
tolerance and inoperative instruments for each custodian account and user 
account and the total number of instruments received for these codes for a 
specified month. Additional selection criteria includes custodian account 
number - date NASA acquired, user number - date NASA acquired, date NASA 
acquired - all, manufacturer's name - date NASA acquired, item name - date 
NASA acquired, manufacturer's name - model number - date NASA acquired, 
manufacturer's name - item name - date NASA acquired. This report is issued 
monthly. 

Calibration Interval Analysis Report (Report 018) .- This report provides 
data for evaluating the effectiveness of a calibration interval determination 
program for both calibration and limited calibration actions. The report lists 
those instruments which were calibrated within +15 days of the scheduled date 
and have condition received codes which identify instruments received in an 
operating condition. The report lists the percentage of instruments received 
in tolerance for both calibration and limited calibration. This report is 
sequenced by item name, manufacturer's name, model number, and calibration 
interval. The report contains data including ECN and last eight condition 
received codes. Additional selection criteria include item name - model 
number, item name - manufacturer's name - date calibration due and all - 
date calibration due. This report is issued annually. 

Work Action Analysis Report (Report 019) .- This report lists the instru- 
ments serviced by Action Taken Codes (Table 50) and provides a breakdown of 
the type of work being performed. This report is sequenced by action taken, 
performing organization, manufacturer's name and model number. The report 
lists data including ECN, item name, last eight condition received codes, 
total service hours, calibration interval, custodian account number, and user 
number. The report lists the total number of items and service hours for each 
performing organization and each action taken code. Additional selection 
criteria includes action taken and performing organization. This report is 
issued annually. 

Property Location Report (Report 020) .- This report lists the location 
of each item and is sequenced by equipment location building, room, and ECN. 

This report is different from a NEMS equipment location report in that it 
also includes the noncontrolled instruments while NEMS contains only 
controlled equipment. The noncontrolled equipment has a metrology number 
assigned to it for identification control only and not accountability. Data 
listed include custodian account number, date calibration due, manufacturer's 
name, model number, and item name. The report lists the total number of items 
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for each building. Additional selection criteria is equipment location building 
and custodian account number. This report is issued on request only. 

Work Action Analysis Report - Summary File (Report 021) .- Since it is not 
mandatory that all instruments at a field Center be included in the NMIS, the 
performing organization may be performing instrument service work that is not 
included in any of the previous analysis reports. This report and Report 105 
were created to record specific data in a summary format for uncontrolled 
items. Report 021 lists by quarter the total number of items serviced for 
each of the action taken codes. This report lists the previous quarter's 
data when the second, third, and fourth quarter reports are issued. There is 
no other selection criteria. This report is issued quarterly. 

Metrology File Detail Item List (Report 100) .- This report contains the 
entire data record to date for each instrument contained in NMIS. This report 
lists all of the data elements identified as required for adequate metrology 
system control. This report has no additional selection criteria and is 
issued on request only. 

Daily Transaction Report (Report 101) . -This report lists the daily trans- 
actions in the NMIS and is sequenced by transaction number and ECN. The report 
also lists reference code, file data element, original entry and revised entry. 
There is no additional selection criteria and the report is issued daily. 

ERROR Codes and Messages (Report 102) .- This report lists all error codes 
and error-code messages used in the NMIS . This report is sequenced by error- 
code and is issued on request only. 

Global Change Report (Report 103) .- This report lists the global changes 
entered into the system and is sequenced by data element number. The report 
lists the changes from, changes to, data processed, reference code, and number 
of records changed. There is no additional selection criteria and the report 
is issued after each transaction and annually. 

Metrology Control Document (Report 104) .- This report is the Metrology 
Control Document which is the standard preprinted form for use in the NMIS. 

Summ a ry File Detail Li st (Report 105) .- This report provides detailed 
information for those instruments not controlled by the NMIS but are serviced. 
This report when combined with Reports 012, 014, and 016 will provide the 
metrology manager with a more complete metrology system performance analysis. 

This report is sequenced by performing organization and action taken. The 
report summarizes data by action taken code such as repair hours, calibrate 
hours, labor cost year to date, parts cost year to date, outside service cost 
year to date, total number of instruments calibrated, total number of 
instruments repaired, and total instruments serviced. Additional selection 
criteria is by performing organization only. The report is issued quarterly. 
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Metrology History File Detail List (Report 106) .- This report lists in 
detail all of the data elements required for an instrument record when stored 
in the history file. This report is identical to Report 100. This report is 
issued on request only. 


CONCLUDING REMARKS 

In 1982 the NASA Metrology and Calibration Workshop made the decision to 
develop an agency-wide metrology data management system which would operate 
in concert with the new NASA Equipment Management System (NEMS) . The 
metrology system would be used by field Centers to recall instruments for 
periodic calibration, to evaluate instrument performance, to summarize and 
report metrology work performance, and to provide other technical and manage- 
ment data. Two meetings, at the Kennedy Space Center and the Jet Propulsion 
Laboratory, held in 1983 resulted in the development of the core data 
elements — some shared with NEMS, some unique to the metrology system. Codes 
for various work actions were adopted and applicable system tables developed. 
In addition 18 system output reports were developed. Another of the major 
accomplishments of these meetings was the preliminary design and adoption of 
the Metrology Control Document (MCD) and the commitment that each field 
Center would use it as a source document for the NASA Metrology Information 
System (NMIS) . The Langley Research Center was assigned lead responsibility 
in the development of NMIS. During detailed development, over a period of 
7 months, several additional data elements were identified, 10 additional 
reports were developed, issuance frequency for reports was established, CRT 
screen formatting completed, the MCD design completed, and the draft of the 
NMIS design document compiled and distributed. Planned future activities 
include a detailed Design Document Review by NASA metrologists at the Langley 
Research Center (LaRC) in May 1984 and the initial system demonstration 
scheduled for July 1984 at LaRC. The NMIS is scheduled for installation at 
LaRC during the last quarter of calendar 1984 with second Center installation 
initiated in January 1985. Installation plans for the other Centers will be 
established at the next Metrology and Calibration Workshop to be held in 
October 1984. 
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NMIS/NEMS 
Data Element 


Description 


M-10/E-10 

M-15/E-12 

M-90/E-200 

M-95/E-202 

M-100/E-204 

M-105/E-210 

M-110/E-212 

M-115/E-214 

M-120/E-222 

M-125/E-230 

M-130/E-232 

M-135/E-30 

M-140/E-40 

M-145/E-42 

M-150/E-44 

M-155/E-46 

M-160/E-60 

M-165/E-72 

M-170/E-78 

M-175/E-80 

M-180/E-86 

M-185/E-90 

M-190/E-102 

M-195/E-104 

M-210/E-150 


* Equipment Control Number (ECN) 

Old Tag Number 

* Labor Cost Last Service 

* Labor Cost Year to Date 

* Labor Cost to Date 

* Parts Cost Last Service 

* Parts Cost Year to Date 

* Parts Cost to Date 

* Date Last Serviced 

* Date Calibrated 

* Date Calibration Due 

* Item Name 
Manufacturer's Code 

* Manufacturer's Name 

* Manufacturer's Model Number 

* Manufacturer's Serial Number 

* Date NASA Acquired 

* Acquisition Document Control Number 
Custodian Account Number 

* Custodian Number 

* Custodian Organization Code 

* User Number 

* Equipment Location Building 

* Equipment Location Room 

* Acquisition Cost 


indicates identified by metrology workshop. 


Figure 1. NEMS data elements required by NMIS. 
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NMIS 

Data Element 


Description 


M-20 

M-25 

M-30 

M-35 

M-40 

M-45 

M-50 

M-55 

M-56 

M-57 

M-60 

M-65 

M-70 

M-75 

M-80 

M-85 

M-86 

M-87 

M-166 

M-200 

M-205 

M-400 

M-410 

M-420 


Recall Identifier 
Recall Entry Date 

* Condition Received 

* Technician Identifier 

* Calibration Interval 

* Action Requested 

* Action Taken 

* Initiate Date 
Transaction Date 
Date Required 

* Repair Hours 

* Calibrate Hours 

* Measurement Discipline 

* Performing Organization 

* Date Repaired 

* Outside Service Cost Last Service 

* Outside Service Cost Year to Date 

* Outside Service Cost to Date 
Job Order Number 

Date Loaned Out 
Date Loaned Due In 
Reserved for Local Data 
Reference Code 
Transaction Number 


*Indicates identified by metrology workshop. 


Figure 2.- NMIS unique data elements required. 
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NASA CALIBRATION 



MIIIHIIH 
CO0 138 


Figure 3.- NMIS instrument identification tag. 
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METROLOGY CONTROL DOCUMENT 


2 
g 
K 5 

si 


1. ITEM NAME 


2. MANUFACTURER 


3. EQUIP. CONTROL NO. 


4. MODEL NO. 


5. SERIAL NO. 


8. BLDG. NO. 


9. ROOM NO. 


10. CUSTODIAN NAME 


6. USER NAME 


7. USER ID 


11. CUS. NO. 


12. CUS. ORG. 


13. OLD TAG NO. 


14. DATE CALIBRATION DUE 


1. ACQ. DATE 


2. ACQUISITION COST 


COST 


7. LAST 
SERVICE 


LABOR 


0 z 
z o 

1 < 

<1 


PARTS 


OUTSIDE 

SERVICE 


8. YEAn TO 
DATE 


9. TOTAL TO 
DATE 


3. ACQUSITION DOCUMENT NO. 


4. CAL. INT. 


5. REC. ENTRY 
DATE 


6. DATE LAST SERV. 


CONDITION RECEIVED LAST x TIMES 


11 . 


ACTION TAKEN LAST x TIMES 


12. REP. HRS. 
LAST x TIMES 


13. CAL. HRS. 
LAST x TIMES 


L L 


1. DATE REQ. 


2. ACT REQ. 


|3. WORK AREA 


4. JOB ORDER 


5. INTITIATE DATE 


£ S 
£ 5 

w < 


6. T.M. APPROVAL 


7. REMARKS 


1. JOB PRIORITY 

2. ACT. REQ. 

ACT. TKN. 

4. COND. REC. 

5. REP. HRS. 

11. CAL. TECH. 

12. REP. TECH 

13. OUTSIDE SERVICE COST 

M. DATE REC. 


15. REMARKS 


16. LOCAL DATA 


Figure 4. NMIS Metrology Control Document 


Front Side 





























17. EQUIPMENT CONTROL NO. 


A, IDENFITICATION NO. 



| I D. LEADS 

STANDARDS & TEST EQUIPMENT USED 


B. CAL. DUE DATE 


A. IDENTIFICATION NO. 


B. CAL. DUE DATE 



A. IDENTIFICATION NO. 


B. CAL. DUE DATE 


ENTER OUT OF TOLERANCE VALUES ONLY 




Figure 5. NMIS Metrology Control Document - Back Side 









INSTRUCTIONS RPR METROLOGY CONTROL DOCUMENT 
**NOTE; AH dates, machine generated op hand written, sre presented as NMDDYY 

USER INFORMATION: 1 — 14 are preprinted upon form generation. 

BACKGROUND INFORMATION : 1-13 are preprinted upon form generation^ necessary changes to 1,2,5, and 8, and certifies 

USER-TM: (TM - technical monitor) User completes 1,2,5, and 8. TM compieteo j,s, • 

approval by signing 7. 4. WORK AREA CODES 

rr n ncrtllTDm mnin: . . . 


2. ACTION REQUIRED CODES 
acceptance test 
special test 
calibration 
decontaminate/clean 
limited calibration 
functional check 


"G" “ maintenance 
"H" ” modify 
"I" « repair 
"J" « other 

"K thru Z" center unique 


& maintained 


4. WORK AREA CODES 

acoustics, vibration, shock 

; n 

pressure & vacuum 

chemical & analytical 

dimensional 

electrical/electronic '* 

frequency stds. & counters 
radiometry & photometry 
temperature & humidity 


"I" b ionizing radiation 
"J" “ microwave & RF 
"K" « oscilloscopes, waveform, 
video & communications 
"L" ” liquid & gas flow 
"M" - mass, force, & torque 
"N thru Z" center unique & 
maintained 


n “ LCllipclOUUAC w* -y 

^TnRATTnN-REPAIR INFORMATION: 1 - 15 completed by appropriate personnel in servicing organization or as local options dictate. 

— 5,6,7 — complete to XX. X manhours. 

s’ rounded to whole dollars from block 21- G. 

13 — rounded to whole dollar. CONDITION RECEIVED CODES 

3. ACTION TAKEN CODES „ A „ _ operat i ve -in tolerance 

"A" - acceptance test (I N I( ” mo “ 1£le „ B n „ ope rative-out of tolerence <1X 

" B " “ s P ecial taSt I adjusted-limited calibration "C" - operative-out of tolerence >1X £2X 

"C - calibrated , , “D'» . operative-out of tolerence >2X <4X 

"D" - decontaminated/cleaned Q (| “ adjuste ca „ E n m opera tive-out of tolerence >4X 

"E;; “ un ^ ua . !!J|. I repaired-limited calibration "F" - operative-out of tolerence indeterminabl. 

"F “ functional check " , . "g" b inoperative 

"G" “ shipped for off site repair calibration "H" - not determined/applicable 

"H" = hold (AWP, manuals, etc.) U 0 jl,o,. M Uhrate "I" “ other-see remarks 

"I" - returned to user unserviced V - c ean j calibration "J thru Z" center unique 6. maintained 

"J" - reject-beyond economical repair "W" “ clean-limited calibration 

"K" - reject-shipped for off site repair "X" - clean-calibrate 

"L" - limited calibration " Y " ” clean-calibra te 

"M" “ maintenance z “ clean-repa r ca reauired programming is local responsibility. 

LOCAL DATA: This section may be used, at local option, for any purp ^ ^ ^rvirlnv oreanization or as local procedures dictate 

REVERSE: G eneral instrument service information. This section will be compieteo Dy servic g g 

Block 17 — Equipment Control Number must be completed manually. 


acceptance test 
special test 
calibrated 

decontaminated /cleaned 

center unique 

functional check 

shipped for off site repair 

hold (AWP, manuals, etc.) 

returned to user unserviced 

reject-beyond economical repair 

reject-shipped for off site repair 

limited calibration 

maintenance 


4. CONDITION RECEIVED CODES 
"A" = operative-in tolerance 
"B" “ operative-out of tolerence <1X 
"C" - operative-out of tolerence >1X <2X 
"D" - operative-out of tolerence >2X <4X 
"E" » operative-out of tolerence >4X 
"F" ” operative-out of tolerence indeterminable 
"G" “ inoperative 

"H" ” not determined/applicable 

"I" b other-see remarks 

"J thru Z" center unique & maintained 


Figure 6.- Instructions for completing Metrology Control Document. 



Table Number 

Table Name 

20 

Recall Identification Table 

30 

Condition Received Table 

45 

Action Requested Table 

50 

Action Taken Table 

70 

Measurement Discipline Table 

75 

Performing Organization Table 

420 

Transaction Number Table 


Figure 7.- NMIS tables required 


Code 

Description 

C 

Calibration 

F 

Functional test 

I 

In situ calibration 

N 

Non recall 

P 

Preventive maintenance 

R 

Reference standard 

S 

Personal safety 

T 

Transfer standard 

W 

Working standard 


Figure 8.- NMIS recall identification codes — 
Table 20. 
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Code 


A 

B 

C 

D 

E 

F 

G 

H 

I 

J-Z 


Description 

Operative - in tolerance 

Operative - out of tolerance < lx 

Operative - out of tolerance > lx < 2x 

Operative - out of tolerance > 2x < 4x 

Operative - out of tolerance > 4x 

Operative - out of tolerance - indeterminable 

Inoperative 

Not determined - not applicable 
Other - see remarks 

Remaining values Center unique and maintained 


Figure 9.- NMIS instrument condition received codes — Table 30. 


Code 

A 

B 

C 

D 

E 

F 

G 

H 

I 

J 

K-Z 


Description 
Acceptance test 
Special test 
Calibration 
Decontaminate/ clean 
Limited calibration 
Functional check 
Maintenance 
Modify 
Repair 
Other 

Remaining values Center unique and 
maintained 


Figure 10.- NMIS action requested codes — Table 45. 
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Code 


Code 


Description 


Acceptance test 
Special test 


Calibrated 


Decontaminated - cleaned 


Center unique 


Functional check 


Shipped for off-site repair 

Hold (awaiting parts, manuals, etc.) 


Returned to user unserviced 


Reject - BER (beyond economical repair) 
Reject — shipped for off— site repair 


Limited calibration 


Figure 11.- Action taken codes- 


Modif ied 



■Table 50. 



Code 


A 

B 

C 

D 

E 

F 

G 

H 

I 

J 

K 

L 

M 

N-Z 


Description 

Acoustics, vibration, shock 
Pressure and vacuum 
Chemical and analytical 
Dimensional 
Electrical/Electronic 
Frequency standards and counters 
Radiometry and photometry 
Temperature and humidity 
Ionizing radiation 
Microwave and RF 

Oscilloscopes, waveform, video, and communications 
Liquid and gas flow 
Mass, force, and torque 

Remaining values Center unique and maintained 


Figure 12.- NMIS measurement discipline codes — Table 50. 


Code 

A 

B 

C 

D 

E 

F 

G 

H 

I-Z 


Description 

Calibration/repair laboratory 
Repair laboratory 
Calibration laboratory 
Standards laboratory 
National Bureau of Standards 
NBS map 

Government primary laboratory (other than NBS) 
NASA map 

Remaining values Center unique and maintained 


Figure 13.- NMIS performing organization codes — Table 75. 
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Transaction Number 


Transaction Name 


01 

02 

03 

04 

05 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 
66 

67 

68 
69 
99 


Receipt of New Instrument by Inspecting Facility 
Receipt of New Instrument by Receiving Facility 
Receive Instrument for Recall 
Return of Record from History File 
Retagging 

New Performing Organization 

Send to Calibration 

Send to Service 

Return from Calibration 

Return from Service 

Cost (change) 

Custodian Account (change) 

User Number (change) 

Instrument Location (change) 

Loan Pool Out 
Loan Pool Returned 
Record Data (change) 

Global (change) 

Calibration Interval Adjustment 
Factory Repair/Service 
Recall Identifier 
Modify Performing Organization 
Lost Tag 
Excess (broken) 

Decontrol (removal of tag) 

Discontinue Performing Organization 


Figure 14.- NMIS transaction number codes — Table 420. 


Table Number 

Table Name 

40 

Manufacturer's Code Table 

78 

Custodian Account Number Table 

90 

User Number Table 

102 

Building Number Table 

252 

NASA Installation Number Table 


Figure 15.- NEMS tables used by NMIS. 
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Report 


Number 

Report Name 

Frequency 

001 

ECN Calibration Master List 

Quarterly 

002 

Calibration User List - ECN Sequence 

On Request 

003 

Calibration User List - Item Name Sequence 

On Request 

004 

Calibration Item Name List 

Annually 

005 

Calibration Model Number List 

On Request 

006 

Calibration Due List - ECN Sequence 

Monthly 

007 

Calibration Due List - Item Name Sequence 

On Request 

008 

Calibration Due List - Performing Organization Sequence 

Monthly 

009 

Calibration Overdue List 

Monthly 

010 

Performing Organization Due/Overdue Status Report 

Daily 

Oil 

Hold Status Report 

Monthly 

012 

Calibration Support Analysis 

Annually 

013 

Calibration Life Cycle Cost Analysis 

Annually 

014 

Production Analysis 

Monthly 

015 

Calibration Weekly Status Report 

Weekly 

016 

Calibration/Maintenance Time Analysis 

Annually 

017 

Out-of-Tolerance and Inoperative Instrument Report 

Monthly 

018 

Calibration Interval Analysis Report 

Annually 


Figure 16.- NMIS reports developed by metrology workshop. 


Report 

Number 

Report Name 

Frequency 

019 

Work Action Analysis Report 

Annually 

020 

Property Location Report 

On Request 

021 

Work Action Analysis Report - Summary File 

Quarterly 

100 

Detail Item List 

On Request 

101 

Daily Transaction Report 

Daily 

102 

Error Codes and Messages 

On Request 

103 

Global Change Report 

Annually 

104 

Metrology Control Document 

On Request 

105 

Summary File Detail List 

On Request 

106 

Metrology History File Detail List 

On Request 


Figure 17.- Additional NMIS reports required. 


Ill 



112 


NATIONAL AERONAUTICS AND SPACE ADMINISTRATION 
REPORT NOt 006 INSTALLATION NAME 

NASA METROLOGY INFORMATION SYSTEM 

SEQUENCED BY: CUSTODIAN ACCOUNT NUMBER 

USER NUMBER CALIBRATION DUE LIST - BCN SEQUENCE 

DATE CALIBRATION DUE 

ECN 


CUSTODIAN ACCOUNT NUMBER, NAME, M/S: XXXXX, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, XXXXXXX 

USER NUMBER, NAME, M/S: XXXXXX, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, XXXXXXX 


DATE 
CAL DUE 

BCN 

ITEM NAME 

MANUFACTURER'S NAME 

MANUFACTURER'S 
MODEL NUMBER 

CAL 

INT 

MEAS 

DISC 

PERF 

ORG 

999999 

XXXXXX 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

xxxxxxxxxxxxxxxxxxxx 

99 

X 

X 


PAGE ZZ9 

RUN DATE MM/DD/YY 


after change in Date Calibration Due: 
TOTAL NUMBER OF ITEMS DUE: ZZ,ZZ9 

after change in User Number: 

TOTAL NUMBER OF ITEMS: ZZ,ZZ9 

after change in Custodian Account Number: 
TOTAL NUMBER OF ITEMS: ZZ,ZZ9 

GRAND TOTAL NUMBER OF ITEMS: ZZ,ZZ9 


1. Sequence: Custodian Account Number (M-170) 

User Number (M-185) 

Date Calibration Due (M— 130) 

ECN (M— 10) 

2. Page Break: User Number 

Custodian Account Number 
Maximum Number of Lines Per Page 

3. Section Break: Date Calibration Due 

4. Total Level: for Date Calibration Due 

for User Number 

for Custodian Account Number 

Grand Total 

5. Selection Criteria: Date Cal Due 

Date Cal Due/Custodian Account Number 
Date Cal Due/Custodian Account Number/ 
User Number 


6. Distribution: 

7. Frequency: Monthly 


Figure 18.- Format of instrument calibration due report. 



LANGLEY'S VIEWS ON NEMS 
BY 

Jeanette W. George, Computer Systems Analyst 
Business Data Systems Division 
Mail Stop 179, Langley Research Center 
FTS 928-2721 


The NEMS system consists of seven Center files and one Langley-unique 
file, the Prior Monthly Transactions (PMT) . The NEMS Monthly Transaction 
file contains the current activity of the working month and is emptied to 
begin a new month. Since there was insufficient time to get all the 
information needed from this file before it was purged, we requested that 
the PMT file be established. This file assists our users in generating 
statistical information on data for periods greater than 1 month. It is 
also used to determine employee workload and productivity and has been 
beneficial as an audit trail on our items. The PMT file will be maintained 
for 12 months. 

In order for anyone to access the NEMS on-line system, he must first 
have his USERID set up. Whenever an attempt is made to enter NEMS, the 
system checks the USERID against the NEMS USERID/ AUTHORITY Table and, if it 
is not on the table, all access is terminated. A user may have access to 
all or part of a subsystem, or may not have access to a particular subsystem 
at all, depending on the level of authority given him. 

There are five NEMS on-line subsystems. They are all menu driven with 
formatted screens. The main menu will display only the subsystems the user 
is authorized to use. Each subsystem can have various levels of authorization 
within it. 

The NEMS Batch System consists of a series of jobs that perform various 
functions ranging from data base updating to reporting to data base maintenance. 
It is designed to run after the on-line system has been brought down. A 
NATURAL program submits the scheduled jobs and monitors their progress. All 
job submission and restarting is automatic and is initiated by the same NEMS 
job. 


JCL used to run the various batch reports and maintenance functions is 
contained in one place. The JCL is automatically submitted to the internal 
reader by the JCL Generator programs based on control switches set in the 
records. For instance, if we are running the monthly cycle, only JCL card 
images with the monthly switch are selected. 

A control record is used to monitor the job flow and the status of each 

job. This record is used to check for the completion of all jobs. At the end 

of the batch system, or if a fatal error occurs, a journal report is produced. 

It serves as an activity log for the run for that day. 


113 



As with all new systems, it is not unusual to encounter various problems. 
After 2 months of actual production it was decided that BDSD and Equipment 
Management personnel would document problem areas and situations experienced 
with NEMS. The documentation included changes we needed at Langley as well 
as other items we felt would assure smooth installation at other Centers. 

The documentation was transmitted to NASA Headquarters as an attachment to a 
letter from the Director for Management Operations. We identified 32 problem 
areas and/or concerns, with most being minor. Of the 32 items, 13 have been 
corrected and most of the others are in the process of being corrected. 

One of Langley's greatest concerns is with the reconciliation between NEMS 
and the General Ledger. Langley's accounting system tracks cost data to the 
penny level. NEMS deals in whole dollar amounts. Therefore, we have no way 
of reconciling the two. The only approach that is acceptable to Langley, unless 
requirements for reconciliation are changed, is for the NEMS files and the 
reports involved in the process be at the penny level. All other NEMS reports 
can remain whole dollars. 

Also to reconcile, Langley needs data to show the difference between the 
previous cost and the new cost for the month . On an input record, the adjustment 
amount is added to the cost and recorded as total amount. The adjusted cost 
is not captured. In order to establish a control between the prior months and 
the current month, a new field needs to be added to capture the adjusted cost 
(debits and credits) . Langley has not reconciled the Equipment account with the 
General Ledger since February 1984. 

Problems with NEMS regular production runs cause concern. Production at 
Langley is run on the second and/or third shift. If a run(s) terminates and/or 
abends in a particular module, we must wait until the next day to resolve NEMS 
problems after consultation with Headquarters personnel. Although Headquarters 
has given Langley excellent response in problem resolution, it is often difficult 
to define the problems by telephone. In addition, the NEMS users cannot use the 
system until problems are solved and the runs completed, which occurs in the 
next night's production. 

NEMS is a very good system and has many outstanding features. However, 
for a successful installation, we must have (1) a good data base to convert to 
NEMS and (2) users and the data processing staff must work together. 
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LaRC Local Area Networks to Support Distributed Computing 


by: Ed P. Riddle 

Langley Research Center 


INTRODUCTION 

LaRC has initiated the development of a Local Area Network (LAN) to support 
a growing distributed computing environment at the Center. The purpose 
of the network is to provide an improved capability (over interactive and 
RJE terminal access) for sharing multi-vendor computer resources. Specifical- 
ly, the network will provide a data highway for the transfer of files between 
mainframe computers, minicomputers, work stations, and personal computers. 

An important influence on the overall network design has been the vital 
need of LaRC researchers to efficiently utilize the large CDC mainframe 
computers in the central scientific computing facility. Although there 
has been a steady migration from a centralized to a distributed computing 
environment at LaRC in recent years, the work load on the central resources 
has increased. This same experience has been noted at other large computing 
facilities. Therefore, major emphasis in the network design has been placed 
on communication with the central resources within the distributed environ- 
ment. The network to be implemented will allow researchers to utilize the 
central resources, distributed minicomputers, work stations, and personal 
computers to obtain the proper level of computing power to efficiently per- 
form thei r jobs. 

LaRC requirements for a local area network cannot be met with a commercially 
available system. As with almost all local area networks of any size, a 
custom design is required, including both hardware and software. LaRC has 
elected to minimize hardware design by building a network around commercially 
available Ethernet products. However, network and application level software 
for the network gateways and various resources on the network will be devel- 
oped in-house. With today's LAN technology, an in-house design of the net- 
work software appears to be the only viable approach to meet LaRC require- 
ments. Following is a review of LaRC plans for the development of a center- 
wide local area network. 

NETWORK CONFIGURATION 

Figure 1 defines a proposed framework within which an integrated data network 
to support distributed computing at LaRC will be developed. The top half 
of Figure 1 depicts the central scientific computing resources which include 
multiple CDC Cyber mainframe computers and a large mass storage system with 
a current capacity of 16 billion words. A major resource at the central 
facility is a CDC Cyber 203 vector processing supercomputer. The bottom 
half of Figure 1 depicts the growing distributed environment at LaRC. 

The total network configuration consists of three levels of network with the 
principal difference between the levels being transmission speed. Three dif- 
ferent networks are used because it is not economically feasible to implement 
a single network with today's technology to meet LaRC's networking require- 
ment. The design goal will be to integrate the different levels of network 
to form what will appear as a single networking environment to the user. 
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Two levels of the network are already in existence at LaRC. An interactive 
computing low-speed network has been in operation for six years. The inter- 

nf^nnTV 5 ! h0Wn J n more detail in Fi 9 ur e 2. The network supports 
U P f^r ° x^ aU ? in l er * ct l™ terminal traffic to various computing resources 
at LaRC. The heart of the network is a digital data switch from Micom Sys- 
tems, Inc. located in the central scientific computing facility. The data 
switch operates similarily to a telephone company central office switch. 

Any terminal on the network can initiate a connection to any computer (or 
terminal) on the network. Although installed initially to support scientific 
computing, the network has in recent years been expanded to support adminis- 
trative computing as well. Requirement for a low-speed networking is expect- 

rrdoht fore ^ ee ® ble future > although the implementation 

might, in the future, be part of an integrated voice/data PBX. 

A high-speed mainframe computer network was installed in the computer center 
Ifrw/ 69 ^ ™ ls . n ® twork » Control Data Corporation's Loosely Coupled Network 
(LCN), provides interconnection between the CDC mainframe computers and the 
mass storage system in the central facility. Three parallel coax trunks, 

each operating at a transmission rate of 50 megabaud, are used as the trans- 
mission medium. 

To optimize the value of a distributed computing environment, a means for 
efficiently transferring large data files between all network resources 
is required. The two existing networks are not suitable for this. The 

ifinn r S?H Ve t e r mina1 network is too slow. It is limited to data rates of 
9600 baud and typically does not provide a means for guaranteeing error-free 
transmission The high-speed LCN network, although fast enough, is too 
expensive. The cost to interface a resource to LCN is $50,000 to $100 000-- 
obviously not practical for workstations, personal computers, and most'mini- 
computers. A new medium-speed network is needed to fill the gap between 
the existing networks and provide a reasonable and cost effective means for 
transferring data files within LaRC's distributed computing environment. 
Iherefore, a network is being developed to support throughput up to one 
megabaud at a hardware cost-per-devi ce of less than $3000. The new network 
shown at the bottom of Figure 1, will have a gateway to the high-speed LCN 
mainframe network. A description of the proposed medium-speed network fol- 


MEDIUM-SPEED FILE TRANSFER NETWORK 

The proposed configuration of the medium-speed file transfer network is 

nr^Unr+c 3 \ The n *; tworl< is designed around Ethernet technology and 

f Ethernet was chosen because it has received by far the greatest 
commercia acceptance and support. Ethernet hardware is currently 
vailable commercially to interface with more computer systems, (including 
DEC minicomputers and IBM personal computers), than any other LAN product. 

I he number of supported devices is growing rapidly. 
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The design concept is that each building, or group of buildings, will contain 
an independent Ethernet network to which minicomputers, workstations, and 
personal computers will be attached. The individual Ethernet clusters will 
then be interconnected via gateways to a ring network using token-passing 
LAN technology. Both the Ethernet and ring networks operate at a 10 megabaud 
transmission rate. Two network technologies will be integrated because 
it is not technically feasible to implement a single Ethernet extending 
to all of the LaRC buildings. The total distance exceeds the one mile limita- 
tion of Ethernet. The token-passing ring does not have this distance limita- 
tion. The multiple Ethernet design allows local data traffic within an 
Ethernet cluster to be confined to that cluster and not impact traffic on 
other parts of the network. This is an important consideration since our 
surveys have indicated that 50-70% of total data traffic will be local. 

A dedicated gateway on the ring network will provide access to the high-speed 
CDC LCN mainframe network. The integrated network as configured in Figure 
3 will allow i nterconnecti vity between network devices. 


NETWORK CHARACTERISTICS AND CAPABILITIES 

It has been necessary to set boundaries on network capability in order to 
develop and implement a LaRC network using reasonable resources (manpower 
and money). The following summarizes the capabilities of the network. 

The network will support full interconnectivity: any network device will 

be able to communicate with any other device at both a network and applica- 
tion level. To provide that interconnectivity, however, it has been neces- 
sary to limit (at least initially) the kinds of equipment and the applica- 
tions that will be supported. Initial implementation will accommodate only 
CDC Cyber mainframe computers, DED PDP/VAX minicomputers, and IBM personal 
computers. File transfers will be the only application initially supported. 

Even though the transmission rate on the network will be 10 megabaud, the 
maximum throughput between any two network devices will be limited by the 
device throughput, which typically has been found to be less than one mega- 
baud. All network gateways will be designed to support throughputs up to 
one megabaud. 

The packet scheme of transmission on both the Ethernet and ring networks 
provides for re-transmission of data when communication errors are detected, 
resulting in negligible error rates on the network. 

An important design criteria has been that no modifications to the computer 
operating systems should be required to accommodate the network software. 

All network software has been designed to operate external to the computer 
operating systems. 

Finally, the network is being designed with the future in mind. The goal 
of the design is a network that is easily expandable and adaptable to new 
LAN technologies. The latter is important because rapid advancements in 
LAN technology result in new and improved concepts and products almost daily. 
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IMPLEMENTATION PLAN AND SCHEDULE 


The development and. implementation of the network will be in four phases. 
The first phase, which is now well underway, is a pilot implementation in 
LaRC's central scientific computing facility. The pilot effort will be 
completed by the end of this calendar year. The second phase will be a 
production implementation of the network, beginning next year, at three 
to six selected sites. Refinements to network design are expected to be 
made as a result of experience gained during the first year of production 
activity. The third and fourth phases of network implementation will be 
a continuation of production implementation at additional sites. The last 
phase is expected to be completed by the end of calendar year 1986. 


STATUS OF NETWORK DEVELOPMENT 

n " on of a ten-station Ethernet pilot network in the central computing 
facility has been completed. The pilot includes a CDC Cyber mainframe com- 
puter, four DEC minicomputers, and five IBM personal computers. This equip- 
ment was not purchased for the network project but is equipment that was, 
and continues to be used for production work. An initial, simplified version 
of network and file transfer software has been developed in-house for all 
network devices. Throughput rates of 100-450 kilobaud between network de- 
vices have been demonstrated. Typically, the limiting factor on throughput 
has been found to be disk I/O on the network devices. The pilot network 
is operational during normal working hours and is available for limited 
production use. 


Two Ethernet clusters on the pilot have been connected to a two-node ring 
and primitive operation of that configuration has been demonstrated. A 
fully-operational three-node pilot ring with three Ethernet clusters is 
expected to be operational in the central computing facility by the end of 
this calendar year. 

The work remaining during this calendar year will be to refine the network 
software that has been developed, adding multi-user capability and providing 
routing and flow control protocols that are required for the ring network. 
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APPENDIX A 

Administrative Data Base Management System 
Technology Conference 
June 6-7 , 1984 
LaRC Activities Center 
AGENDA 


June. . 6 .>... 19. 8 .4 

9:00 Opening Remarks and General Announcements 

(LaRC/Andrew Swanson & NTD/Jim Radosevich) 

9:15 Strategies for Converting to a DBMS Environment 
(ARC/Dave Durban) 

9:50 Effective Organizational Solutions for 

Implementation of DBMS Software Packages 
(ET-Space Telescope Dev. Div./BDM/Doug Jones) 

10:17 Break 

10:35 Administrative Automation in a Scientific Environment 

(GSPC/Joyce R. Jarrett presented by: E. R. Schmerling) 

11:05 The Administrative Window Into the Integrated DBMS 

(KSC/Georgia H. Brock) 

11:23 Lunch 

1:00 A User View of Office Automation or the Integrated 
Workstation (GSFC/E. R. Schmerling) 

1:32 Langley Experience with ADABAS/NATURAL 

(LaRC/Andrew Swanson, Coordinator) 

-Strip and Load Data (LaRC/Richard Jones) 

-Natural Graphics (LaRC/Richard Jones) 

-File Transfer to IBM PC's (LaRC/ Jerome Hoerger) 

-Status Tracking System for Reports (LaRC/ Jean Huffman) 
-Acquisition Support Systems (LaRC/Vernon Vann) 

-Financial Management Support Systems (LaRC/ Judy Evans) 
-Personnel Management Support Systems (LaRC/Sidney Pauls) 

2:50 Break 

3:00 Langley Experience with ADABAS/NATURAL - Continued 

(LaRC/Andrew Swanson, Coordinator) 

3:50 Roundtable Discussion Concerning Technical Considerations in 
(LaRC/Andrew Swanson, Coordinator) 

- Use Of ADABAS/NATURAL 

- Use of COM-PLETE versus CICS or TSO (or other TP 

Monitors) 

- Other "NASA Uniform Systems" Matters 
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Administrative Data Base Management System 
Technology Conference 
June 6-7, 1984 
LaRC Activities Center 
AGENDA 


June 7 . 1984 

9:00 The NBS Data Management Technology Program 

(NBS/Helen M. Wood presented by: Roy Saltman) 

9:30 Data Communication Between Data Terminal Equipment 
and the JPL Administrative DBMS 
(JPL/R. Iverson) 

10:05 Break 

10:25 NASA Metrology Information System - A NEMS Subsystem 
(LaRC/Earl S. German Jr. and Fredrick A. Kern) 

10:45 Roundtable Discussion Concerning NEMS 

(LaRC/Andrew Swanson, Coordinator) 

-Overview of NEMS & PACER (LaRC/ Jeff Parker) 
-Langley's views on NEMS (LaRC/PRC/ Jeanette W. 
George) 

-Response to Problems Identified (NIE/John Gaff) 
12:00 Lunch 

1:00 LaRC Local Area Networks to Support Distributed 

Computing (LaRC/Ed P. Riddle) 

1:30 Approached to Management of Engineering Information 

(LaRC/Dr. Robert E. Fulton presented by: Charles 
Blackbourne) 

2:00 Summary Remarks/Plans for Next Conference 

(HQ/Jim Radosevich) 

2:15 Break 

2:30 Tours of LaRC Facilities: 

1. National Transonic Facility 

2. Analysis and Computation Division Facilities 

3. Langley Visitor Center 

4:00 Adjourn 
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